Yes, absolutely! We would dump and reload all of our large databases in a heartbeat if there were an option for a
64-bitxid!
Another quick question: When this database took itself offline to avoid transaction id wraparound, we opted for a
vacuumfreeze in single-user mode. Was that the right choice? In other words, what is the fastest way to get a database
backonline when this occurs? Maybe a plain vacuum would have been better?
Thanks!
Natalie
On Aug 12, 2013, at 11:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Natalie Wenz <nataliewenz@ebureau.com> 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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
