Yes, absolutely! We would dump and reload all of our large databases in a heartbeat if there were an option for a 64-bit xid! Another quick question: When this database took itself offline to avoid transaction id wraparound, we opted for a vacuum freeze in single-user mode. Was that the right choice? In other words, what is the fastest way to get a database back online when this occurs? Maybe a plain vacuum would have been better? Thanks! Natalie On Aug 12, 2013, at 11:15 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Natalie Wenz <nataliewenz@xxxxxxxxxxx> writes: >> ... With the speed postgres is capable of, and the ever-falling prices >> of storage making larger, faster databases possible, has the possibility >> of changing the transaction id to a 64-bit (or even 128-bit!) value been >> considered? > > Not terribly seriously --- the penalties from making row headers 8 bytes > bigger have always seemed to outweigh the advantages. (128 bits is right > out; we don't even have 128-bit LSNs.) > > We'd probably take a patch to make 64-bit XIDs available as a compile-time > option, if someone wanted to do the legwork to write and test it. But > let me ask you this: if such an option existed, would you be willing to > dump and reload your database to take advantage of it? The conversion > costs of changing row header format seem like they'd discourage exactly > those people whom such a feature could help. > > regards, tom lane > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
