Subject: tid_blockno() and tid_offset() accessor functions

From: Ayush Tiwari <[email-masked]>
Date: Sat, 28 Feb 2026 00:29:20 +0530

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

---

From: Ayush Tiwari <[email-masked]>
Date: Sun, 8 Mar 2026 01:13:13 +0530

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

---

From: Alexandre Felipe <[email-masked]>
Date: Sun, 8 Mar 2026 17:17:44 +0000

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.
I think it would be nice to also support
SELECT * FROM table WHERE tid_block(tid) BETWEEN b1 AND b2;

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?

Regards

On Sat, Mar 7, 2026 at 7:43 PM Ayush Tiwari <[email-masked]>
wrote:

> 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.
>
>> 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.
>>

---

From: Ayush Tiwari <[email-masked]>
Date: Mon, 9 Mar 2026 13:20:13 +0530

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-masked]> wrote:

> On 3/8/26 18:17, Alexandre Felipe wrote:
> > 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.
>
> 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.
> >
> > 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
>
>

---

From: Greg Sabino Mullane <[email-masked]>
Date: Mon, 9 Mar 2026 09:34:46 -0400

On Sun, Mar 8, 2026 at 3:31 PM Tomas Vondra <[email-masked]> wrote:

> be more careful on input, it's too late for tid_block() to decide what to
> do with an "impossible" TID value.
>

This one doesn't sit right with me. I think it's not too late. No reason
why tid_block cannot be stricter here than tid itself and complain. Other
than that, the patch looks good to me.

Cheers,
Greg

---

From: Andres Freund <[email-masked]>
Date: Mon, 9 Mar 2026 10:01:53 -0400

Hi,

> than that, the patch looks good to me.

I don't see any advantage in that. These functions are useful for inspecting
tid values that come from some source. When would you *ever* gain *anything*
from not being able to see the block / offset of a tid datum that you already
have?

This isn't an end user focused type / set of accessor functions were being
particularly careful about input validation will perhaps prevent users from
making mistakes...

Greetings,

Andres Freund

---

From: Ayush Tiwari <[email-masked]>
Date: Wed, 11 Mar 2026 19:20:01 +0530

Hi,

Thank you all for the reviews and discussion!

On the strictness question raised by Greg — I agree with Andres here. These
functions are meant for inspecting tid values that already exist, so
rejecting "impossible" values like (-1,0) would not be providing any real
benefit. I believe the tid input function is the appropriate place for any
validation, and these assessors should just faithfully report what's in the
datum.

Regards,
Ayush

---

From: Masahiko Sawada <[email-masked]>
Date: Wed, 11 Mar 2026 14:48:08 -0700

On Fri, Feb 27, 2026 at 10:59 AM Ayush Tiwari
<[email-masked]> 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:
>
> 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.
>

How about adding the subscripting support for tid data type? For
example, ctid[0] returns bigint and ctid[1] returns int.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

---

From: Andres Freund <[email-masked]>
Date: Wed, 11 Mar 2026 17:50:32 -0400

Hi,

> example, ctid[0] returns bigint and ctid[1] returns int.

That just seems less readable and harder to find to me.  I think it'd also
make the amount of required code noticeably larger?

Greetings,

Andres

---

From: Masahiko Sawada <[email-masked]>
Date: Thu, 12 Mar 2026 09:51:50 -0700

> make the amount of required code noticeably larger?

Yeah, using the dedicated functions would be more intuitive than using
magic numbers 1 and 2, and require less code.

Regards,

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 13 Mar 2026 14:27:23 +0100

> magic numbers 1 and 2, and require less code.

Also, you can use one-argument functions like field names, like 
tid.tid_blockno, so it's definitely more intuitive that way.

---

From: Andres Freund <[email-masked]>
Date: Fri, 13 Mar 2026 12:24:53 -0400

Hi,

On 2026-03-08 01:13:13 +0530, Ayush Tiwari wrote:
> From 92e3657d85b13355563ba4c447ddf89fcb4c4b3e Mon Sep 17 00:00:00 2001
> From: Ayush Tiwari <[email-masked]>
> Date: Sat, 7 Mar 2026 18:27:36 +0000
> Subject: [PATCH v2] Add tid_block() and tid_offset() accessor functions
>
> Add two new built-in SQL functions to extract the components of a tid
> (tuple identifier) value:
>
>   tid_block(tid) -> bigint   -- extract block number
>   tid_offset(tid)  -> integer  -- extract offset number
>
> These provide a clean, efficient alternative to the common workaround
> of ctid::text::point for decomposing TID values. The text-based hack
> is fragile, inefficient, and unavailable outside of SQL contexts.
>
> tid_block() returns int8 (bigint) because BlockNumber is uint32,
> which exceeds the range of int4. tid_offset() returns int4 (integer)
> because OffsetNumber is uint16, which fits safely in int4.
>
> Both functions use the NoCheck accessor variants from itemptr.h,
> are marked leakproof, and include regression tests covering typical
> values, boundary conditions, NULL handling, and round-trip identity.

> +++ b/doc/src/sgml/func/func-tid.sgml
> @@ -0,0 +1,73 @@
> + <sect1 id="functions-tid">
> +  <title>TID Functions</title>
> +
> +  <indexterm zone="functions-tid">
> +   <primary>TID</primary>
> +   <secondary>functions</secondary>
> +  </indexterm>
> +
> +  <indexterm>
> +   <primary>tid_block</primary>
> +  </indexterm>
> +
> +  <indexterm>
> +   <primary>tid_offset</primary>
> +  </indexterm>
> +
> +  <para>
> +   For the <type>tid</type> data type (described in <xref
> +   linkend="datatype-oid"/>), <xref linkend="functions-tid-table"/>

Seems odd to reference the datatype-oid, that's barely mentioning the tid type
and tid is not an oid like type either (like e.g. regtype is).

> +   shows the functions available for extracting the block number and
> +   tuple offset.  These functions are commonly used with the
> +   <structfield>ctid</structfield> system column.
> +  </para>

I know some other places do that too, but "shows the functions" sounds odd to
me. I'd just say "These are listed in ..." or such.

I'd remove the "available for extracting the block number and tuple offset",
as that's bound to become inaccurate and just restates the table contents.

> --- a/doc/src/sgml/func/func.sgml
> +++ b/doc/src/sgml/func/func.sgml
> @@ -59,6 +59,7 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
>  &func-formatting;
>  &func-datetime;
>  &func-enum;
> +&func-tid;
>  &func-geometry;
>  &func-net;
>  &func-textsearch;

I'd add it somewhere more alphabetically fitting. Unfortunately the list isn't
fully ordered right now, but no need to make it even worse...

Greetings,

Andres Freund

---

From: Matthias van de Meent <[email-masked]>
Date: Fri, 13 Mar 2026 18:08:04 +0100

> tid.tid_blockno, so it's definitely more intuitive that way.

TIL.

As for naming; I'd personally prefer to have 'heap' included in the
names here (e.g. heaptid_blkno(tid) or heap_blkno[_of](tid)), because
not all AMs may map tid.blkno exactly to a block number in the main
fork. While PostgreSQL (in core) currently only knows about the heap
AM, we should probably keep clear of pretending that all tableAMs
produce TIDs that behave exactly like heap's do.

Matthias van de Meent
Databricks (https://www.databricks.com)

---

From: Greg Sabino Mullane <[email-masked]>
Date: Fri, 13 Mar 2026 13:18:09 -0400

On Fri, Mar 13, 2026 at 1:08 PM Matthias van de Meent <
[email-masked]> wrote:

> As for naming; I'd personally prefer to have 'heap' included in the names
> here (e.g. heaptid_blkno(tid) or heap_blkno[_of](tid)), because
> not all AMs may map tid.blkno exactly to a block number in the main fork.

All our docs and code mention blocks and offsets as the components of a
tid, so -1 on making things more obtuse.

-- 
Cheers,
Greg

---

From: Andres Freund <[email-masked]>
Date: Fri, 13 Mar 2026 13:54:48 -0400

Hi,

> produce TIDs that behave exactly like heap's do.

Meh. As long as tids themselves are split like they are, without any
variability of the amount of space dedicated for either component, I don't see
any advantage in that.

Greetings,

Andres Freund

---

From: Ayush Tiwari <[email-masked]>
Date: Sat, 14 Mar 2026 14:31:32 +0530

Hi,

Thanks for the review!

Attaching a patch with all document changes, removed the cross-reference to
datatype-oid entirely. I've moved the &func-tid; entry in func.sgml to
directly follow &func-textsearch;, which fits better alphabetically, and
reworded the introductory paragraph to be much more concise, directly
pointing to the table.

Regards,
Ayush

---

From: Andres Freund <[email-masked]>
Date: Sun, 5 Apr 2026 15:30:09 -0400

Hi,

> reworded the introductory paragraph to be much more concise, directly

Pushed this after making some small changes (removed some IMO unnecessary
comments, replaced <type>TID</type> with <acronym/>, as TID is not the type's
name, ...).

I was reminded of this thread while in the process of doing some performance
validation that required getting all the block numbers from an index scan,
which required me to remember (ctid::text::point)[0], which I find to be very
ugly.

Closed the CF entry.

Thanks for the patch!

Greetings,

Andres Freund

---

From: Álvaro Herrera <[email-masked]>
Date: Sun, 5 Apr 2026 21:44:48 +0200

Hello

> which required me to remember (ctid::text::point)[0], which I find to be very

Thanks for this patch!  I agree that the statu quo was sort of embarrasing :-)

Regards

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/