Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id 5f91073c1623c417de353728884102063232748f.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, 2021-05-03 at 13:22 -0400, Robert Haas wrote:
> to look and work like heap TIDs; that is, there had better be a block
> number portion and an item number portion,

Right (at least for now).

> and the item number had
> better be smaller than MaxOffsetNumber,

That's not clear to me at all, and is the whole reason I began this
thread.

  a. You say "smaller than MaxOffsetNumber", but that's a little weird.
If an offset can't be MaxOffsetNumber, it's not really the maximum, is
it?
  b. If you actually meant "less than or equal to MaxOffsetNumber",
that will fail with the GIN posting list issue raised in my first
email. Do you agree that's a bug?
  c. Why can't we go all the way up to MovedPartitionsOffsetNumber - 1?
Right now, MaxOffsetNumber is poorly named, because it actually
represents the a number slightly higher than the maximum number of
items that can fit on a page. That essentially wastes 5 bits of address
space for no obvious reason.

> and if you want bitmap scans
> to run reasonably quickly, the block number had also better
> correspond
> to physical locality to some degree.

Right (at least for now).

Regards,
    Jeff Davis






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

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