Re: Challenges preventing us moving to 64 bit transaction id (XID)?

On 06/05/2017 11:49 AM, Tianzhou Chen wrote:
> Hi Pg Hackers,
>
> XID wraparound seems to be quite a big concern and we introduce
> changes like “adding another frozen bit to each page”
> [http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html
> <http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html>
> to tackle this. I am just wondering what’s the challenges preventing
> us from moving to 64 bit xid? This is the previous thread I find
> https://www.postgresql.org/message-id/CAEYLb_UfC%2BHZ4RAP7XuoFZr%2B2_ktQmS9xqcQgE-rNf5UCqEt5A%40mail.gmail.com
> <https://www.postgresql.org/message-id/CAEYLb_UfC+HZ4RAP7XuoFZr+2_ktQmS9xqcQgE-rNf5UCqEt5A@mail.gmail.com>,
> the only answer there is:
>
> “ The most obvious reason for not using 64-bit xid values is that
> they require more storage than 32-bit values. There is a patch
> floating around that makes it safe to not forcibly safety shutdown
> the server where currently it is necessary, but it doesn't work by
> making xids 64-bit.
> "
>
> I am personally not quite convinced that is the main reason, since I
> feel for database hitting this issue, the schema is mostly
> non-trivial and doesn’t matter so much with 8 more bytes. Could some
> postgres experts share more insights about the challenges?

That quote is accurate. We don't want to just expand XIDs to 64 bits,
because it would significantly bloat the tuple header. PostgreSQL's
per-tuple overhead is already quite large, compared to many other systems.

The most promising approach to tackle this is to switch to 64-bit XIDs
in in-memory structures, and add some kind of an extra epoch field to
the page header. That would effectively give you 64-bit XIDs, but would
only add one a field to each page, not every tuple.

- Heikki