Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 5f91073c1623c417de353728884102063232748f.camel@j-davis.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: MaxOffsetNumber for Table AMs
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Incorrect snapshots while promoting hot standby node when 2PC is used
Next
From: Jeff Davis
Date:
Subject: Re: MaxOffsetNumber for Table AMs