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

From Peter Geoghegan
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id CAH2-Wzm=MW481RZoTt=Ukg9s+FM4utjJD_CudY5MpLOCGtKMwQ@mail.gmail.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: MaxOffsetNumber for Table AMs
List pgsql-hackers
On Fri, Apr 30, 2021 at 2:13 PM Jeff Davis <pgsql@j-davis.com> wrote:
> FWIW, this is not a problem in my table AM. I am fine having different
> TIDs for each version, just like heapam.

This means that we are largely in agreement about the general nature
of the problem. That seems like a good basis to redefine TID-like
identifiers so that they can accommodate what you want to do.

> For index-organized tables it does seem like an interesting problem.

I strongly suspect that index-organized tables (or indirect indexes,
or anything else that assumes that TID-like identifiers map directly
to logical rows as opposed to physical versions) are going to break
too many assumptions to ever be tractable. Assuming I have that right,
it would advance the discussion if we could all agree on that being a
non-goal for the tableam interface in general. This would allow us to
clearly discuss how to solve the remaining problem of accommodating
column stores and suchlike. That seems hard, but much more tractable.

The fact that the tableam has almost no non-goals has always bothered
me a bit. Especially on this particular point about purely logical
TID-like identifiers.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: MaxOffsetNumber for Table AMs
Next
From: Peter Geoghegan
Date:
Subject: Re: MaxOffsetNumber for Table AMs