Date: Thu, 20 Oct 2022 11:02:52 +0800
From: Zhang Mingli <zmlpostgres@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Message-ID: <17c99615-2c3b-4e4e-9d0b-424a66a7bccd@Spark>
In-Reply-To: <8b3760ce-5599-47d7-a4ca-06749e4d0b10@Spark>
References: <8b3760ce-5599-47d7-a4ca-06749e4d0b10@Spark>
Subject: Documentation refinement for Parallel Scans
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="6350ba61_235ba861_1189"
Archived-At: 
 <https://www.postgresql.org/message-id/17c99615-2c3b-4e4e-9d0b-424a66a7bccd%40Spark>
Precedence: bulk

--6350ba61_235ba861_1189
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

=46ound documents about parallel scan may be not so accurate.

As said in parallel.smgl:

=60=60=60
In a parallel sequential scan, the table's blocks will be divided among t=
he cooperating processes.=C2=A0Blocks are handed out one at a time, so th=
at access to the table remains sequential.
=60=60=60

To my understanding, this was right before. Because we return one block i=
f a worker ask for before commit 56788d2156.
As comments inside table=5Fblock=5Fparallelscan=5Fnextpage:
=60=60=60
Earlier versions of this would allocate the next highest block number to =
the next worker to call this function.
=60=60=60
And from commit 56788d2156, each parallel worker will try to get ranges o=
f blocks =E2=80=9Cchunks=22.
Access to the table remains sequential inside each worker=E2=80=99s proce=
ss, but not across all workers or the parallel query.
Shall we update the documents=3F

Regards,
Zhang Mingli

--6350ba61_235ba861_1189
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hi,<br />
<br />
=46ound documents about parallel scan may be not so accurate.<br />
<br />
As said in parallel.smgl:<br />
<br />
=60=60=60<br />
In a parallel sequential scan, the table's blocks will be divided among t=
he cooperating processes.&=23160;<span style=3D=22color:=23ff0000=22>Bloc=
ks are handed out one at a time, so that access to the table remains sequ=
ential.</span><br />
=60=60=60<br />
<br />
To my understanding, this was right before. Because we return one block i=
f a worker ask for before commit 56788d2156.<br />
As comments inside table=5Fblock=5Fparallelscan=5Fnextpage:<br />
=60=60=60<br />
Earlier versions of this would allocate the next highest block number to =
the next worker to call this function.<br />
=60=60=60<br />
And from commit 56788d2156, each parallel worker will try to get ranges o=
f blocks =E2=80=9Cchunks=22.<br />
Access to the table remains sequential inside each worker=E2=80=99s proce=
ss, but not across all workers or the parallel query.<br />
Shall we update the documents=3F<br /></div>
</div>
<div name=3D=22messageSignatureSection=22><br />
<div dir=3D=22auto=22><span style=3D=22color: var(--textColor); backgroun=
d-color: var(--backgroundColor);=22>Regards,</span><br /></div>
<div dir=3D=22auto=22>Zhang Mingli</div>
</div>
</body>
</html>

--6350ba61_235ba861_1189--