Re: Make TID Scans recalculate the TIDs less often
От | David Rowley |
---|---|
Тема | Re: Make TID Scans recalculate the TIDs less often |
Дата | |
Msg-id | CAApHDvpicvz9+eBxrN9QuQJu5b=hCBPC88Gu_t9_+iZb4YvH8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Make TID Scans recalculate the TIDs less often (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: Make TID Scans recalculate the TIDs less often
|
Список | pgsql-hackers |
On Wed, 17 Sept 2025 at 18:29, Andrey Borodin <x4mmm@yandex-team.ru> wrote: > I heard of following use-case: data transferring system partition big tables by ctid ranges to mimic parallel secscan,but with many network connections. Some performance improvement was claimed and connection failure resistance (whenone connection was broken only one partition is rescanned with same snapshot). > Would your patch improve performance of such case? I suspect they're just running a SELECT * to a single table "WHERE ctid BETWEEN" some fixed range of TIDs. If that's the case then this won't help as there are no rescans, therefore the TID Range is only calculated once. Also, I imagine TID Range Scans are less affected than TID Scans simply because TidExprListCreate() is more complex than TidRangeEval(). 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. David
В списке pgsql-hackers по дате отправления: