Re: Make TID Scans recalculate the TIDs less often
От | Andrey Borodin |
---|---|
Тема | Re: Make TID Scans recalculate the TIDs less often |
Дата | |
Msg-id | E46AAE87-715A-459D-B4D7-2F13F89CE0BC@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Make TID Scans recalculate the TIDs less often (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Make TID Scans recalculate the TIDs less often
|
Список | pgsql-hackers |
> On 17 Sep 2025, at 14:51, David Rowley <dgrowleyml@gmail.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)||')')::tidfrom 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 haveparticular infomask bits). But, fortunately, it's not that frequent case. It's always "plumbing", not a "regular databaseusage". Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: