From: Tom Lane <tgl@sss.pgh.pa.us>
To: Natalie Wenz <nataliewenz@ebureau.com>
cc: pgsql-admin@postgresql.org
Subject: Re: vacuum freeze performance, wraparound issues
In-reply-to: <273F3E90-053B-4137-BE4D-3E7115A6A12E@ebureau.com>
References: <273F3E90-053B-4137-BE4D-3E7115A6A12E@ebureau.com>
Comments: In-reply-to Natalie Wenz <nataliewenz@ebureau.com>
 message dated "Mon, 12 Aug 2013 18:39:25 -0500"
Date: Tue, 13 Aug 2013 00:15:24 -0400
Message-ID: <5056.1376367324@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

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