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
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() |