Re: MaxOffsetNumber for Table AMs

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MaxOffsetNumber for Table AMs
Date: 2021-04-30 21:22:40
Message-ID: CAH2-Wzm=MW481RZoTt=Ukg9s+FM4utjJD_CudY5MpLOCGtKMwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 30, 2021 at 2:13 PM Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-04-30 22:19:05 Re: MaxOffsetNumber for Table AMs
Previous Message Jeff Davis 2021-04-30 21:13:03 Re: MaxOffsetNumber for Table AMs