Horton

Re: Support tid range scan in parallel?

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Cary Huang <cary.huang@highgo.ca>
Cc: Junwang Zhao <zhjwpku@gmail.com>, Rafia Sabih <rafia.pghackers@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-14T07:14:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix possibly uninitialized HeapScanDesc.rs_startblock

  2. Add parallelism support for TID Range Scans

  3. Avoid repeating loads of frozen ID values.

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