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