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

From Peter Geoghegan
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id CAH2-Wzkc7tNF4t=r8Vn4+c+uXo08ibdFwBPFnz33sJefF2wOcA@mail.gmail.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: MaxOffsetNumber for Table AMs
List pgsql-hackers
On Wed, May 5, 2021 at 12:43 PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> I believe that it cannot be "just" an additive thing, at least not
> through a normal INCLUDEd column, as you'd get duplicate TIDs in the
> index, with its related problems. You also cannot add it as a key
> column, as this would disable UNIQUE indexes; one of the largest use
> cases of global indexes. So, you must create specialized
> infrastructure for this identifier.

You're just quibbling about the precise words that I used. Of course
it is true that there must be some sense in which a global index
partition key attribute will need to be special to the implementation
-- how else could a global index enforce uniqueness? That was clearly
implied.

> And when we're already adding specialized infrastructure, then this
> should probably be part of a new TID infrastructure.

This is a non-sequitur.

> And if we're going to change TID infrastructure to allow for more
> sizes (as we'd need normal TableAM TIDs, and global index
> partition-identifying TIDs), I'd argue that it should not be too much
> more difficult to create an infrastructure for 'new TID' in which the
> table AM supplies type, size and strict ordering information for these
> 'new TID's.
>
> And if this 'new TID' size is not going to be defined by the index AM
> but by the indexed object (be it a table or a 'global' or whatever
> we'll build indexes on), I see no reason why this 'new TID'
> infrastructure couldn't eventually support variable length TIDs; or
> constant sized usertype TIDs (e.g. the 3 int columns of the primary
> key of a clustered table).

You're not considering the big picture. It's not self-evident that
anybody will ever have much use for a variable-width TID in their
table AM, at least beyond some fairly simple scheme -- because of the
fundamental issue of TID not working as a stable identifier of logical
rows in Postgres. If it was very clear that there would be *some*
significant benefit then the costs might start to look reasonable. But
there isn't. "Build it and they will come" is not at all convincing to
me.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: .ready and .done files considered harmful
Next
From: Stephen Frost
Date:
Subject: Re: .ready and .done files considered harmful