Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id CAH2-Wz=VcVQS-j6njTVMuo0RkM8tdkKiPqcOFuf824tX_csSJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, May 3, 2021 at 7:41 AM Robert Haas <robertmhaas@gmail.com> wrote:
> So here. The complexity of getting a table AM that does anything
> non-trivial working is formidable, and I don't expect it to happen
> right away. Picking one that is essentially block-based and can use
> 48-bit TIDs is very likely the right initial target because that's the
> closest we have now, and there's no sense attacking the hardest
> variant of the problem first.

It doesn't have to be block-based -- that's not what Jeff is
proposing. It just has to be able to accept the restriction that
indexes must have a unique TID-like identifier for each version (not
quite a version actually -- whatever the equivalent of a HOT chain
is). This is a restriction that Jeff had pretty much planned on
working within before starting this thread (I know this because we
spoke about it privately).

It's quite possible to rule out an index-organized table design
without ruling out a column store with logical TID-like identifiers,
that aren't block-based. It's fair to wonder if not tightening up the
rules for TID-like identifiers is actually helping table AM authors in
practice. I think it's actually making things harder.

-- 
Peter Geoghegan



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Granting control of SUSET gucs to non-superusers
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Granting control of SUSET gucs to non-superusers