pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedDocumentation refinement for Parallel Scans
3+ messages / 2 participants
[nested] [flat]
* Documentation refinement for Parallel Scans
@ 2022-10-20 03:02 Zhang Mingli <zmlpostgres@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Zhang Mingli @ 2022-10-20 03:02 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
Found documents about parallel scan may be not so accurate.
As said in parallel.smgl:
```
In a parallel sequential scan, the table's blocks will be divided among the cooperating processes. Blocks are handed out one at a time, so that access to the table remains sequential.
```
To my understanding, this was right before. Because we return one block if a worker ask for before commit 56788d2156.
As comments inside table_block_parallelscan_nextpage:
```
Earlier versions of this would allocate the next highest block number to the next worker to call this function.
```
And from commit 56788d2156, each parallel worker will try to get ranges of blocks “chunks".
Access to the table remains sequential inside each worker’s process, but not across all workers or the parallel query.
Shall we update the documents?
Regards,
Zhang Mingli
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Documentation refinement for Parallel Scans
@ 2022-10-20 06:33 David Rowley <dgrowleyml@gmail.com>
parent: Zhang Mingli <zmlpostgres@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: David Rowley @ 2022-10-20 06:33 UTC (permalink / raw)
To: Zhang Mingli <zmlpostgres@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, 20 Oct 2022 at 16:03, Zhang Mingli <zmlpostgres@gmail.com> wrote:
> As said in parallel.smgl:
>
> In a parallel sequential scan, the table's blocks will be divided among the cooperating processes. Blocks are handed out one at a time, so that access to the table remains sequential.
> Shall we update the documents?
Yeah, 56788d215 should have updated that. Seems I didn't expect that
level of detail in the docs. I've attached a patch to address this.
I didn't feel the need to go into too much detail about how the sizes
of the ranges are calculated. I tried to be brief, but I think I did
leave enough in there so that a reader will know that we don't just
make the range length <nblocks> / <nworkers>.
I'll push this soon if nobody has any other wording suggestions.
Thanks for the report.
David
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index c37fb67065..e556786e2b 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -272,8 +272,9 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
<listitem>
<para>
In a <emphasis>parallel sequential scan</emphasis>, the table's blocks will
- be divided among the cooperating processes. Blocks are handed out one
- at a time, so that access to the table remains sequential.
+ be divided into ranges and 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>
<listitem>
Attachments:
[text/plain] fix_parallel_seqscan_docs.patch (786B, ../../CAApHDvrzaSUEyoEOORrZXvELddXaoit1e+Pp07qOu+9o6K390A@mail.gmail.com/2-fix_parallel_seqscan_docs.patch)
download | inline diff:
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index c37fb67065..e556786e2b 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -272,8 +272,9 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
<listitem>
<para>
In a <emphasis>parallel sequential scan</emphasis>, the table's blocks will
- be divided among the cooperating processes. Blocks are handed out one
- at a time, so that access to the table remains sequential.
+ be divided into ranges and 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>
<listitem>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Documentation refinement for Parallel Scans
@ 2022-10-20 20:31 David Rowley <dgrowleyml@gmail.com>
parent: David Rowley <dgrowleyml@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: David Rowley @ 2022-10-20 20:31 UTC (permalink / raw)
To: Zhang Mingli <zmlpostgres@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, 20 Oct 2022 at 19:33, David Rowley <dgrowleyml@gmail.com> wrote:
> I'll push this soon if nobody has any other wording suggestions.
Pushed.
Thanks for the report.
David
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-10-20 20:31 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-10-20 03:02 Documentation refinement for Parallel Scans Zhang Mingli <zmlpostgres@gmail.com>
2022-10-20 06:33 ` David Rowley <dgrowleyml@gmail.com>
2022-10-20 20:31 ` David Rowley <dgrowleyml@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox