Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id 3268871.1619800534@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: MaxOffsetNumber for Table AMs
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Fri, 2021-04-30 at 11:06 -0400, Tom Lane wrote:
>> My thought at the moment is that all APIs above the AM level ought
>> to be redefined to use uint64 for tuple identifiers.

> Do you mean that indexes would be expected to hold a uint64, a 48-bit
> int (that directly maps to a uint64), or still hold an ItemPointerData?

ISTM that would be up to the index AM.  We'd need some interlocks on
which index AMs could be used with which table AMs in any case, I think.

It'd likely not be hard for existing index AMs to be repurposed to store
"any 48-bit TID", but extending them to full 64-bit TIDs may be
impractical.

I think the hard part may really be in places like tidbitmap.c, which
one would wish to be AM-independent, but right now it's quite specific
to heap-style TIDs.  Maybe we can think of a way to parameterize it.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: MaxOffsetNumber for Table AMs
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_amcheck contrib application