On Sat, 6 Dec 2025 at 09:12, Cary Huang <[email protected]> wrote: > > within each worker process. > > </para> > > </listitem> > > + <listitem> > > + <para> > > + In a <emphasis>parallel tid range scan</emphasis>, the range of > > blocks > > + will be subdivided into smaller ranges which are shared among the > > + cooperating processes. Each worker process will complete the > > scanning > > + of its given range of blocks before requesting an additional range > > of > > + blocks. > > + </para> > > + </listitem> > > </itemizedlist> > > I may be missing some info or wrong but my impression is that > the range of blocks is actually set by the leader worker and is > the same among all the cooperating workers rather than > subdivided. The workers fetches as many blocks to process as > they can (similar to sequential scan in parllel) as long as the > block falls within the TID range. Current block number is > stored in parallel scan descriptor in shared memory so workers > will not fetch the same block during scan.
If you look at what's written for Seq Scans, namely "In a parallel sequential scan, the table's blocks will be divided into ranges and shared among the cooperating processes.", this is talking about how the blocks are shared between workers, i.e no two workers operate on the same block. If that happened we'd get wrong results. The "range" that this is talking about was introduced in 56788d215 to fix the kernel readhead detection issue with Parallel Seq Scans (the kernel was not detecting sequential file access due to multiple processes cooperating on the sequential access). With Parallel TID Range Scans, we already have the "TID Range" of blocks to scan, so I had to come up with wording that didn't say "we divide the range into ranges and distribute ...", so I used "subdivided". I'm happy if someone comes up with better wording, but I don't see anything factually wrong with what's there. The TID Range of blocks is set by whichever worker process gets there first. That might not be the leader. David
