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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Timeline ID in backup_label file
Следующее
От: Andres Freund
Дата:
Сообщение: Expression based aggregate transition / combine function invocation