On Thu, 14 Aug 2025 at 10:03, Cary Huang <cary.huang@highgo.ca> wrote:
> ExecTidRangeScanInitializeWorker() is called by each parallel worker and is also
> updated such that it will not set the TID limits again.
This only works for setting the block range. What about the
TableScanDescData.rs_mintid and rs_maxtid? They'll be left unset in
the parallel worker, and heap_getnextslot_tidrange() needs to do
filtering based on those, which isn't going to work correctly when
they don't get set.
Here are the results from scanning a 10 million row table with the v9 patch:
# set parallel_setup_Cost=0;
# set parallel_tuple_cost=0;
# select count(*) from huge where ctid >= '(10,10)' and ctid <= '(10000,10)';
count
--------
629175
# select count(*) from huge where ctid >= '(10,10)' and ctid <= '(10000,10)';
count
--------
600247
# select count(*) from huge where ctid >= '(10,10)' and ctid <= '(10000,10)';
count
--------
621943
(1 row)
The workers are ending their scan early because
heap_getnextslot_tidrange() returns false on the first call from the
parallel worker.
# set max_parallel_workers_per_Gather=0;
# select count(*) from huge where ctid >= '(10,10)' and ctid <= '(10000,10)';
count
---------
2257741
David
