On Wed, Jan 14, 2026 at 9:38 AM Bertrand Drouvot <[email protected]> wrote: > > Hi, > > On Fri, Jan 09, 2026 at 11:34:09AM +0100, Jakub Wartak wrote: > > On Tue, Dec 9, 2025 at 10:11 AM Jakub Wartak > > <[email protected]> wrote: > > > > > > Hi Heikki, thanks for having a look! > > > > > > On Mon, Dec 8, 2025 at 11:12 AM Heikki Linnakangas <[email protected]> > > > wrote: > > > > > > > > On 08/12/2025 11:54, Jakub Wartak wrote: > > > > > While thinking about cons, the only cons that I could think of is that > > > > > when we would be exposing something as 32-bits , then if the following > > > > > major release changes some internal structure/data type to be a bit > > > > > more heavy, it couldn't be exposed anymore like that (think of e.g. > > > > > 64-bit OIDs?) > > > > > > > > > > Any help, opinions, ideas and code/co-authors are more than welcome. > > > > > > > Expanding it to 64 bit seems fine as far as performance is concerned. I > > > > think the difficult and laborious part is to design the facilities to > > > > make use of it. > > > > > > Right, I'm very interested in hearing what could be added there/what > > > people want (bonus points if that is causing some performance issues > > > today and we do not have the area covered and exposing that would fit > > > in 32-bits ;) ) > > > > > > > OK, so v3 is attached. Changes in v3: > > Thanks for the new version! > > It looks like that it needs a rebase. Also, FWIW, a quick scan shows a few > numbers of "XXX" and elog calls commented out (that are probably used during > your own debugging?).
Yes, indeed, that's intentional right now - it's more like a draft rather than something that should be polished. To be honest I would like to avoid sinking more time on it, if the sole idea gets shot down or there is opposition due e.g. to concerns of exposing 32-bit relfilenodes that way (see that 56-bit relfilenode idea). -J.
