At FOSDEM someone asked how long 64 bit Transaction-IDs will last.
To refresh: PostgreSQL is currently using 32 bits for the TXID, and is good for around 4 billion transactions:
At FOSDEM someone asked how long 64 bit Transaction-IDs will last.
To refresh: PostgreSQL is currently using 32 bits for the TXID, and is good for around 4 billion transactions:
Imagine, you have a table and a colum is defined NOT NULL. You (and I) expect, that NULL arguments will not go into the table, but instead get rejected.
devx.com has a fair comparisation about the two databases engines, not looking at the speed but at more important points like features, ACID, transactions or commercial and 24/7/365 support. In other words, all the things you want, if you decide to use a database in a production environment.
Letztens in einem IRC Channel:
Diese wannabe Datenbank macht immer alles anders:
Just stumbled about a curiosity: there are 82 functions in the current PostgreSQL part of PHP. Functions like pg_select(), which takes from you the burden of writing a SELECT ... FROM tablename or pg_delete(), pg_insert() and pg_update() which all does, what do you expect: SELECT, DELETE, INSERT or UPDATE, and do the error checking. There are even 7 different functions for getting your results back into PHP.
But there is no function for starting, committing or rolling back a transaction. It seems, the message about the usefulness of transaction has yet not reached the PHP developers. Not that I’m surprised, the standard PHP/MySQL user seems to have no need for transactions …