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

From Peter Geoghegan
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id CAH2-WznP4KEic8JewNhyKOxhjuAnqWJ7EDECQ9m=dwbM2XNgMg@mail.gmail.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On Mon, May 3, 2021 at 10:22 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> 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.

Perhaps that's true in theory, but the resulting design seems likely
to be useless in the end. In any case I believe that systems that
generally use a heap but give you the choice of using an IoT (I'm
really thinking of Oracle) tend to not have many users that actually
avail of IoTs. On modern flash storage the trade-off made by an IoT or
clustered index design seems like the wrong one on average. You're
saving about 1 I/O on average with a PK lookup, which just isn't that
much of an upside compared to the many downsides.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: MaxOffsetNumber for Table AMs
Next
From: Andres Freund
Date:
Subject: Re: Incorrect snapshots while promoting hot standby node when 2PC is used