Re: Make TID Scans recalculate the TIDs less often - Mailing list pgsql-hackers

From David Rowley
Subject Re: Make TID Scans recalculate the TIDs less often
Date
Msg-id CAApHDvpicvz9+eBxrN9QuQJu5b=hCBPC88Gu_t9_+iZb4YvH8w@mail.gmail.com
Whole thread Raw
In response to Re: Make TID Scans recalculate the TIDs less often  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Make TID Scans recalculate the TIDs less often
List 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 by date:

Previous
From: Ilia Evdokimov
Date:
Subject: Re: Use merge-based matching for MCVs in eqjoinsel
Next
From: Andrey Borodin
Date:
Subject: Re: Make TID Scans recalculate the TIDs less often