Re: Support tid range scan in parallel?

Cary Huang <cary.huang@highgo.ca>

From: Cary Huang <cary.huang@highgo.ca>
To: "Steven Niu" <niushiji@gmail.com>
Cc: "pgsql-hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-27T22:07:53Z
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.

Hi Steven

thanks for the review!

 > I have two comments:
 > 1. Does table_beginscan_parallel_tidrange() need an assert of relid,
 > like what table_beginscan_parallel() did?
 > Assert(RelationGetRelid(relation) == pscan->phs_relid);

In the v6 rebased patch, the assert has become:

Assert(RelFileLocatorEquals(relation->rd_locator, pscan->phs_locator));

rather than:

Assert(RelationGetRelid(relation) == pscan->phs_relid);

table_beginscan_parallel_tidrange() already has the proper assert line
similar to what table_beginscan_parallel() has.

 > 2. The new field phs_numblock in ParallelBlockTableScanDescData
 > structure has almost the same name as another field phs_nblocks. Would
 > you consider changing it to another name, for example,
 > phs_maxnumblocktoscan?

I actually had a similar thought too, phs_nblocks and phs_numblock are
very similar but are quite different. But I still left the name as phs_numblock
because I want to keep it consistent (kind of) with the 'numBlks' used in
heap_set_tidrange() in heapam.c. The comments besides their declaration
should be enough to describe their differences without causing confusion.

Best regards
Cary