Re: Support tid range scan in parallel?

On Sat, 6 Dec 2025 at 09:12, Cary Huang <cary(dot)huang(at)highgo(dot)ca> 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