Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?
Date
Msg-id CAD21AoDydRvJrkmRozcXeC-5cig7HsrYwEzRjNKE6toFWx8=DQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Nov 28, 2017 at 4:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
>> pg_prune_xid makes sense only for heap pages.  Once we introduce special
>> area for heap pages, we can move pg_prune_xid there and save some bytes in
>> index pages.  However, this is an optimization not directly related to
>> 64-bit xids.  Idea is that if we anyway change page format, why don't apply
>> this optimization as well?  But if we have any doubts in this, it can be
>> removed with no problem.
>
> My first reaction is that changing the page format seems like a
> non-starter, because it would break pg_upgrade.

IIUC xid-lsn ranges patch[1] doesn't require the page format
conversion. Is there any reason we can not go on that way? FWIW, I've
rebased the patch to current HEAD.

[1] https://www.postgresql.org/message-id/5242F8BF.6010807%40vmware.com

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Timeline ID in backup_label file
Next
From: Andres Freund
Date:
Subject: Expression based aggregate transition / combine function invocation