Re: Make TID Scans recalculate the TIDs less often

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
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:31:44
Message-ID: CAApHDvroAnYTx3GG-ebhZkRe9JiENke0x5jdh17nw4Rfx+tKNg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 17 Sept 2025 at 22:13, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> 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".

Thanks for sharing that one. If that UPDATE did do a Nested Loop join
with a TID Scan on the inner side, the optimisation I have in the
patch *wouldn't* be applied as a parameter is changing that genuinely
does need the TidList to be recalculated over again.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vitaly Davydov 2025-09-17 10:49:39 Re: Newly created replication slot may be invalidated by checkpoint
Previous Message Maxime Schoemans 2025-09-17 10:16:44 [PATCH] Check that index can return in get_actual_variable_range()