Re: MaxOffsetNumber for Table AMs

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MaxOffsetNumber for Table AMs
Date: 2021-05-05 20:08:51
Message-ID: CAH2-Wzkc7tNF4t=r8Vn4+c+uXo08ibdFwBPFnz33sJefF2wOcA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 5, 2021 at 12:43 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-05-05 20:13:08 Re: .ready and .done files considered harmful
Previous Message Robert Haas 2021-05-05 20:00:56 Re: .ready and .done files considered harmful