Re: MaxOffsetNumber for Table AMs

On Mon, May 3, 2021 at 7:41 AM Robert Haas <robertmhaas(at)gmail(dot)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