Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id 79e4c7d85bf75e7bc6d7e8e6c741f6473210c322.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: MaxOffsetNumber for Table AMs
Список pgsql-hackers
On Fri, 2021-04-30 at 08:36 -0700, Peter Geoghegan wrote:
> Compatibility with index AMs is more than a matter of switching out
> the tuple identifier -- if you invent something that has totally
> different performance characteristics for index AMs, then it's likely
> to break tacit assumptions about the cost of certain things.

I think it would be reasonable to document and expect that table AMs
offer some locality of access for tuples with similar IDs. Do you think
we need something stronger than that?

> Plus deduplication ameliorates problems with version churn
> in
> indexes -- presumably the same problems will exist when any new table
> AM is used, and so it'll be useful to address the same problems in
> the
> same way.

I got lost after "presumably the same problems", can you explain?

> I agree that it might well be useful to make TIDs fully logical (not
> "physiological" -- physical across blocks, logical within blocks) for
> some new table AM. Even then, it would still definitely be a good
> idea
> to make these logical TID values correlate with the physical table
> structure in some way.

Agreed.

Regards,
    Jeff Davis




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Procedures versus the "fastpath" API
Следующее
От: Tom Lane
Дата:
Сообщение: Re: MaxOffsetNumber for Table AMs