Hello, Thanks for the review!
On the return types: I chose int8 for tid_block() deliberately because BlockNumber is uint32. If we used int4, block numbers >= 2^31 would silently appear as negative values, which seems worse than using the wider type. PostgreSQL already uses bigint to represent uint32 values in other catalog/system functions (e.g., pg_control_checkpoint). The wrapping test actually demonstrates exactly this — (-1,0) correctly shows 4294967295 rather than -1. For tid_offset(), int4 is the natural safe mapping for uint16 (OffsetNumber). You're right that practical offsets are well below 2^13, but int4 costs nothing extra and is consistent. Happy to hear other opinions on the type choices though! Regards, Ayush On Mon, 9 Mar 2026 at 01:01, Tomas Vondra <[email protected]> wrote: > On 3/8/26 18:17, Alexandre Felipe wrote: > > That was something I was surprised to learn, that we can check TID, do > > queries by TID intervals, but we can't get pages from TID, when I was > > trying to analyse how many pages on average a certain query would touch > > for different users. > > True. The conversion to "point" is the traditional way to do this, but > having functions to access the fields is cleared I think. > > > I think it would be nice to also support > > SELECT * FROM table WHERE tid_block(tid) BETWEEN b1 AND b2; > > > > Not sure. Functions are opaque for the scan, i.e. it can't treat it as a > scan key easily, because it could do anything. So this would require > teaching the TidScan that "tid_block" is a special case. > > I believe this should be doable through "support procedures", which can > be attached to pg_proc entries. So tid_block would have a "prosupport" > pointing at a function, implementing SupportRequestIndexCondition. Which > would translate the clause on tid_block() to a range condition on the > underlying tid. > > For inspiration see starts_with(), and text_starts_with_support support > procedure (or rather like_regex_support). > > However, that seems out of scope for this initial patch. > > > I wouldn't bother to support block number above 2^31 or block offsets > > above 2^15. > > > > This test shows that it assumes wrapping > > -- (-1,0) wraps to blockno 4294967295 > > SELECT tid_block('(-1,0)'::tid); > > tid_block > > ------------ > > 4294967295 > > > > You could just stick with that, I am sure that someone with a table > > having more than 2B pages on a table will understand that. > > for tid_offset I don't think it is even possible. If the maximum page > > size is limited to 2^15, must have a header and each offset has a line > > pointer aren't offsets limited to something smaller than 2^13? > > > > No opinion. For displaying the bogus TID value (like "(-1,0)") it's > probably OK to show values that are a bit weird. If anything, we should > be more careful on input, it's too late for tid_block() to decide what > to do with an "impossible" TID value. > > regards > > -- > Tomas Vondra > >
