On Mon, Nov 13, 2023 at 2:52 PM Andres Freund <andres@anarazel.de> wrote:
> This scheme would open up space per page that would now be available for > plenty of other things; the encoding in the header and the corresponding > available space in the footer would seem to open up quite a few options > now, no?
Sure, if you're willing to rewrite the whole cluster to upgrade and willing to permanently sacrifice some data density. If the stored data is actually specific to the page - that is the place to put the data. If not, then the tradeoff is much more complicated IMO.
Of course this isn't a new problem - storing the page size on each page was just silly, it's never going to change across the cluster and even more definitely not going to change within a single relation.
Crazy idea; since stored pagesize is already a fixed cost that likely isn't going away, what if instead of the pd_checksum field, we instead reinterpret pd_pagesize_version; 4 would mean "no page features", but anything 5 or higher could be looked up as an external page feature set, with storage semantics outside of the realm of the page itself (other than what the page features code itself needs to know); i.e,. move away from the on-page bitmap into a more abstract representation of features which could be something along the lines of what you were suggesting, including extension support.
It seems like this could also support adding/removing features on page read/write as long as there was sufficient space in the reserved_page space; read the old feature set on page read, convert to the new feature set which will write out the page with the additional/changed format. Obviously there would be bookkeeping to be done in terms of making sure all pages had been converted from one format to another, but for the page level this would be straightforward.
Just thinking aloud here...
In other crazy idea space … if the page didn’t have enough space to allow for the desired features then make any insert/update actions forcibly have to choose a different page for the new tuple, while allowing delete’s to do their usual thing, and then when vacuum comes along and is able to clean up the page and remove the all dead tuples, it could then enable the features on the page that are desired…
