Horton

Thread

Commits

  1. Add tid_block() and tid_offset() accessor functions

  1. tid_blockno() and tid_offset() accessor functions

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-02-27T18:59:20Z

    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

  2. Re: tid_blockno() and tid_offset() accessor functions

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-03-07T19:43:13Z

    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
>

  3. Re: tid_blockno() and tid_offset() accessor functions

    Alexandre Felipe <o.alexandre.felipe@gmail.com> — 2026-03-08T17:17:44Z

    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 <ayushtiwari.slg01@gmail.com>
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.
>
> 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
>>
>

  4. Re: tid_blockno() and tid_offset() accessor functions

    Tomas Vondra <tomas@vondra.me> — 2026-03-08T19:31:22Z

    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

  5. Re: tid_blockno() and tid_offset() accessor functions

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-03-09T07:50:13Z

    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 <tomas@vondra.me> 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
>
>

  6. Re: tid_blockno() and tid_offset() accessor functions

    Greg Sabino Mullane <htamfids@gmail.com> — 2026-03-09T13:34:46Z

    On Sun, Mar 8, 2026 at 3:31 PM Tomas Vondra <tomas@vondra.me> wrote:

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

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

  7. Re: tid_blockno() and tid_offset() accessor functions

    Andres Freund <andres@anarazel.de> — 2026-03-09T14:01:53Z

    Hi,

On 2026-03-09 09:34:46 -0400, Greg Sabino Mullane wrote:
> On Sun, Mar 8, 2026 at 3:31 PM Tomas Vondra <tomas@vondra.me> wrote:
> 
> > 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.
> >
> 
> 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.

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

  8. Re: tid_blockno() and tid_offset() accessor functions

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-03-11T13:50:01Z

    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

On Mon, 9 Mar 2026 at 19:32, Andres Freund <andres@anarazel.de> wrote:

> Hi,
>
> On 2026-03-09 09:34:46 -0400, Greg Sabino Mullane wrote:
> > On Sun, Mar 8, 2026 at 3:31 PM Tomas Vondra <tomas@vondra.me> wrote:
> >
> > > 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.
> > >
> >
> > 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.
>
> 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
>

  9. Re: tid_blockno() and tid_offset() accessor functions

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-03-11T21:48:08Z

    On Fri, Feb 27, 2026 at 10:59 AM 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`

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

  10. Re: tid_blockno() and tid_offset() accessor functions

    Andres Freund <andres@anarazel.de> — 2026-03-11T21:50:32Z

    Hi,

On 2026-03-11 14:48:08 -0700, Masahiko Sawada wrote:
> On Fri, Feb 27, 2026 at 10:59 AM 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`
> 
> How about adding the subscripting support for tid data type? For
> 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

  11. Re: tid_blockno() and tid_offset() accessor functions

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-03-12T16:51:50Z

    On Wed, Mar 11, 2026 at 2:50 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2026-03-11 14:48:08 -0700, Masahiko Sawada wrote:
> > On Fri, Feb 27, 2026 at 10:59 AM 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`
> >
> > How about adding the subscripting support for tid data type? For
> > 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?

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

Regards,

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

  12. Re: tid_blockno() and tid_offset() accessor functions

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-13T13:27:23Z

    On 12.03.26 17:51, Masahiko Sawada wrote:
> On Wed, Mar 11, 2026 at 2:50 PM Andres Freund <andres@anarazel.de> wrote:
>>
>> Hi,
>>
>> On 2026-03-11 14:48:08 -0700, Masahiko Sawada wrote:
>>> On Fri, Feb 27, 2026 at 10:59 AM 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`
>>>
>>> How about adding the subscripting support for tid data type? For
>>> 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?
> 
> Yeah, using the dedicated functions would be more intuitive than using
> 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.

  13. Re: tid_blockno() and tid_offset() accessor functions

    Andres Freund <andres@anarazel.de> — 2026-03-13T16:24:53Z

    Hi,

On 2026-03-08 01:13:13 +0530, Ayush Tiwari wrote:
> From 92e3657d85b13355563ba4c447ddf89fcb4c4b3e Mon Sep 17 00:00:00 2001
> From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
> 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

  14. Re: tid_blockno() and tid_offset() accessor functions

    Matthias van de Meent <boekewurm+postgres@gmail.com> — 2026-03-13T17:08:04Z

    On Fri, 13 Mar 2026 at 14:27, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 12.03.26 17:51, Masahiko Sawada wrote:
> > On Wed, Mar 11, 2026 at 2:50 PM Andres Freund <andres@anarazel.de> wrote:
> >>
> >> Hi,
> >>
> >> On 2026-03-11 14:48:08 -0700, Masahiko Sawada wrote:
> >>> On Fri, Feb 27, 2026 at 10:59 AM 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`
> >>>
> >>> How about adding the subscripting support for tid data type? For
> >>> 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?
> >
> > Yeah, using the dedicated functions would be more intuitive than using
> > 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.

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)

  15. Re: tid_blockno() and tid_offset() accessor functions

    Greg Sabino Mullane <htamfids@gmail.com> — 2026-03-13T17:18:09Z

    On Fri, Mar 13, 2026 at 1:08 PM Matthias van de Meent <
boekewurm+postgres@gmail.com> 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

  16. Re: tid_blockno() and tid_offset() accessor functions

    Andres Freund <andres@anarazel.de> — 2026-03-13T17:54:48Z

    Hi,

On 2026-03-13 18:08:04 +0100, Matthias van de Meent 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. 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.

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

  17. Re: tid_blockno() and tid_offset() accessor functions

    Ayush Tiwari <ayushtiwari.slg01@gmail.com> — 2026-03-14T09:01:32Z

    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

On Fri, 13 Mar 2026 at 23:24, Andres Freund <andres@anarazel.de> wrote:

> Hi,
>
> On 2026-03-13 18:08:04 +0100, Matthias van de Meent 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. 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.
>
> 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
>

  18. Re: tid_blockno() and tid_offset() accessor functions

    Andres Freund <andres@anarazel.de> — 2026-04-05T19:30:09Z

    Hi,

On 2026-03-14 14:31:32 +0530, Ayush Tiwari wrote:
> 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.

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

  19. Re: tid_blockno() and tid_offset() accessor functions

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-04-05T19:44:48Z

    Hello

On 2026-Apr-05, Andres Freund wrote:

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

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/