From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | MaxOffsetNumber for Table AMs |
Date: | 2021-04-30 07:46:21 |
Message-ID: | 0bbeb784050503036344e1f08513f13b2083244b.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The notion of TID is based on pages and line pointers, which makes
sense for heapam, but that's not likely to make sense for a custom
table AM.
The obvious answer is to make a simple mapping between a TID and
whatever makes sense to the AM (for the sake of discussion, let's say a
plain row number).
The most natural thing would be to say that we have 48 bits, so it can
just be a 48-bit number. Of course, there are some restrictions on
valid values that complicate this:
* InvalidBlockNumber of 0xFFFFFFFF. Not a problem.
* InvalidOffsetNumber of 0. Not a problem.
* MaxOffsetNumber of 2048. Does this limit really apply to table AMs?
It just seems like it's used when scanning heap or index pages for
stack-allocated arrays. For a table AM it appears to waste 5 bits.
* ginpostinglist.c:itemptr_to_uint64() seems to think 2047 is the max
offset number. Is this a bug?
As a table AM author, I'd like to know what the real limits are so that
I can use whatever bits are available to map from TID to row number and
back, without worrying that something will break in the future. A few
possibilities:
1. Keep MaxOffsetNumber as 2048 and fix itemptr_to_uint64().
2. Change MaxOffsetNumber to 2047. This seems likely to break
extensions that rely on it.
3. Define MaxOffsetNumber as 65536 and introduce a new
MaxItemsPerPage as 2048 for the stack-allocated arrays. We'd still need
to fix itemptr_to_uint64().
Thoughts?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-04-30 08:17:48 | Re: Replication slot stats misgivings |
Previous Message | Bharath Rupireddy | 2021-04-30 07:06:07 | Re: Enhanced error message to include hint messages for redundant options error |