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>, 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 18:05:30 |
Message-ID: | CAH2-WznP4KEic8JewNhyKOxhjuAnqWJ7EDECQ9m=dwbM2XNgMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 3, 2021 at 10:22 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-05-03 18:10:50 | Re: Incorrect snapshots while promoting hot standby node when 2PC is used |
Previous Message | Jeff Davis | 2021-05-03 17:57:26 | Re: MaxOffsetNumber for Table AMs |