Re: MaxOffsetNumber for Table AMs

On Fri, Apr 30, 2021 at 10:04 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Fri, 2021-04-30 at 08:36 -0700, Peter Geoghegan wrote:
> > Compatibility with index AMs is more than a matter of switching out
> > the tuple identifier -- if you invent something that has totally
> > different performance characteristics for index AMs, then it's likely
> > to break tacit assumptions about the cost of certain things.
>
> I think it would be reasonable to document and expect that table AMs
> offer some locality of access for tuples with similar IDs. Do you think
> we need something stronger than that?

I don't know. This conversation is still too abstract for me to be
able to take a firm position. ISTM that we tend to talk about the
table AM in excessively abstract terms. It would be a lot easier if we
had clear fixed goals for a small number of additional table AMs.

> > Plus deduplication ameliorates problems with version churn
> > in
> > indexes -- presumably the same problems will exist when any new table
> > AM is used, and so it'll be useful to address the same problems in
> > the
> > same way.
>
> I got lost after "presumably the same problems", can you explain?

Well, there are now two things in nbtree that specifically help with
version churn caused by non-HOT updates: deduplication, and bottom-up
index deletion (especially the latter). Presumably any new table AM
will have something like non-HOT updates. Though they may rarely be a
problem (say because the new table AM isn't really for OLTP), whenever
they are a problem they'll be a very big problem. It seems like a good
idea to have the same index AM level protections against accumulating
version-churn index tuples in an unbounded way.

More generally, it seems like a good idea to try to make new table AMs
reasonably close to heapam insofar as possible. The reality is that
everything evolved around heapam, and that that's likely to matter in
all kinds of ways that nobody fully understands just yet. We have a
somewhat abstract table AM interface, which is good, but that doesn't
mean that table AMs can be designed as if it was a green field
situation.

--
Peter Geoghegan