Re: tid_blockno() and tid_offset() accessor functions - Mailing list pgsql-hackers

From Ayush Tiwari
Subject Re: tid_blockno() and tid_offset() accessor functions
Date
Msg-id CAJTYsWVK6rw++WU94=gFk5ZR5ZXhT3BYOFxhm6tT9xOGG-drnA@mail.gmail.com
Whole thread
In response to tid_blockno() and tid_offset() accessor functions  (Ayush Tiwari <ayushtiwari.slg01@gmail.com>)
Responses Re: tid_blockno() and tid_offset() accessor functions
Re: tid_blockno() and tid_offset() accessor functions
List pgsql-hackers
Hello,

Attaching a V2-patch post rebasing due to oid conflict with the latest main branch. In addition to that changing the sql function name for tid block number to tid_block and adding document related changes.

Please review and let me know your thoughts.

Regards,
Ayush

On Sat, 28 Feb 2026 at 00:29, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
Hi hackers,

As of now we don't have any built-in way to extract the block and offset components from a TID. When people need to group by page (like for bloat analysis) or filter by specific blocks, they usually end up using the `ctid::text::point` hack:

    SELECT (ctid::text::point)[0]::bigint AS blockno,
           (ctid::text::point)[1]::int    AS offset
    FROM my_table;

This works, but it's pretty clunky, relies on the text representation, and isn't great if you're trying to parse TIDs outside of SQL.

The attached patch adds two simple accessor functions:
- `tid_blockno(tid) -> bigint`
- `tid_offset(tid) -> integer`

A couple of quick notes on the implementation I went for:
- `tid_blockno` returns `int8` since `BlockNumber` is `uint32` and could overflow `int4`.
- `tid_offset` returns `int4` since `OffsetNumber` is `uint16`.
- Both are marked leakproof and strict.
- I used the `NoCheck` macros from `itemptr.h` so they safely handle user-supplied literals like `(0,0)`.

Please let me know what you think!

Regards,
Ayush
Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition