Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? |
Дата | |
Msg-id | CAD21AoDydRvJrkmRozcXeC-5cig7HsrYwEzRjNKE6toFWx8=DQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: