Re: MaxOffsetNumber for Table AMs

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(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-05-03 17:22:39
Message-ID: CAEze2WiY2jn8U0JV0p+cLeCUkJT5_s_jqthaYa8Xm=5avOXoBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 3 May 2021 at 19:00, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Mon, May 3, 2021 at 9:45 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > But if you're saying those identifiers have to be fixed-width and 48
> > (or even 64) bits, I disagree that we wish to have such a requirement
> > in perpetuity.
>
> Once you require that TID-like identifiers must point to particular
> versions (as opposed to particular logical rows), you also virtually
> require that the identifiers must always be integer-like (though not
> necessarily block-based and not necessarily 6 bytes). You've
> practically ensured that clustered index tables (and indirect indexes)
> will never be possible by accepting this.

For IoT, as far as I know, one of the constraints is that there exists
some unique constraint on the table, which also defines the ordering.
Assuming that that is the case, we can use <unique key> + <inserting
transaction id> to identify tuple versions.

With regards,

Matthias van de Meent.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-05-03 17:23:17 Re: Granting control of SUSET gucs to non-superusers
Previous Message Robert Haas 2021-05-03 17:22:00 Re: MaxOffsetNumber for Table AMs