Re: Make TID Scans recalculate the TIDs less often

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Make TID Scans recalculate the TIDs less often
Date: 2025-09-17 10:13:00
Message-ID: E46AAE87-715A-459D-B4D7-2F13F89CE0BC@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 17 Sep 2025, at 14:51, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> What you'd need for this to ever be slow is lots of rescans, so
> something like TID Scan on the inside of a nested loop. If you look at
> ExecReScanTidScan() you'll see it pfrees the tss_TidList, which
> requires that the list gets built all over again on the next call to
> TidNext(). It's the call to TidListEval() that is potentially
> expensive due to the expression evaluation, memory allocation, sorting
> and distinct work.

Occasionally (when dealing with corruption) I do stuff like

begin;
update public.tablename set description = description where ctid in (select ('('||b.blkno::text||','||(x::text)||')')::tid from generate_series(1,300) x, blocks b);

in some forms they are actually joins. Also, pageinspecting things out is always a join (CTAS a copy of table rows that have particular infomask bits). But, fortunately, it's not that frequent case. It's always "plumbing", not a "regular database usage".

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxime Schoemans 2025-09-17 10:16:44 [PATCH] Check that index can return in get_actual_variable_range()
Previous Message David Rowley 2025-09-17 09:51:34 Re: Make TID Scans recalculate the TIDs less often