Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id CAH2-Wz=VcVQS-j6njTVMuo0RkM8tdkKiPqcOFuf824tX_csSJw@mail.gmail.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: MaxOffsetNumber for Table AMs
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Granting control of SUSET gucs to non-superusers
Next
From: Chapman Flack
Date:
Subject: Re: Granting control of SUSET gucs to non-superusers