Re: MaxOffsetNumber for Table AMs
От | Matthias van de Meent |
---|---|
Тема | Re: MaxOffsetNumber for Table AMs |
Дата | |
Msg-id | CAEze2WiY2jn8U0JV0p+cLeCUkJT5_s_jqthaYa8Xm=5avOXoBw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: MaxOffsetNumber for Table AMs (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: MaxOffsetNumber for Table AMs
|
Список | pgsql-hackers |
On Mon, 3 May 2021 at 19:00, Peter Geoghegan <pg@bowt.ie> wrote: > > On Mon, May 3, 2021 at 9:45 AM Robert Haas <robertmhaas@gmail.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.
В списке pgsql-hackers по дате отправления: