Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id CAH2-WznP4KEic8JewNhyKOxhjuAnqWJ7EDECQ9m=dwbM2XNgMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: MaxOffsetNumber for Table AMs
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Incorrect snapshots while promoting hot standby node when 2PC is used