pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedTypo in 15.3.4
4+ messages / 3 participants
[nested] [flat]
* Typo in 15.3.4
@ 2024-07-25 03:47 PG Doc comments form <noreply@postgresql.org>
2024-07-25 17:07 ` Re: Typo in 15.3.4 David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: PG Doc comments form @ 2024-07-25 03:47 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: grantgryczan@gmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/parallel-plans.html
Description:
In section 15.3.4, I believe "multiple results sets" is a typo for "multiple
result sets". It says:
> Plans that involve appending multiple results sets can therefore achieve
coarse-grained parallelism even when efficient partial plans are not
available.
It's also possible this should say "multiple results" rather than "multiple
result sets". I'm unsure what exactly this sentence is trying to
communicate, possibly because I'm only learning Postgres (by reading the
docs), and I don't understand what partial and non-partial children mean
from the previous sentences in the context of this section. (Perhaps that
should also be improved on? Unless it was already explained previously and
I've merely forgotten, but I couldn't find that phrasing elsewhere in the
documentation.)
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Typo in 15.3.4
2024-07-25 03:47 Typo in 15.3.4 PG Doc comments form <noreply@postgresql.org>
@ 2024-07-25 17:07 ` David G. Johnston <david.g.johnston@gmail.com>
2024-07-29 14:00 ` Re: Typo in 15.3.4 Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 4+ messages in thread
From: David G. Johnston @ 2024-07-25 17:07 UTC (permalink / raw)
To: grantgryczan@gmail.com; pgsql-docs@lists.postgresql.org
On Thu, Jul 25, 2024 at 9:50 AM PG Doc comments form <noreply@postgresql.org>
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/parallel-plans.html
> Description:
>
> In section 15.3.4, I believe "multiple results sets" is a typo for
> "multiple
> result sets". It says:
>
> > Plans that involve appending multiple results sets can therefore achieve
> coarse-grained parallelism even when efficient partial plans are not
> available.
>
> It's also possible this should say "multiple results" rather than "multiple
> result sets".
Good catch, and an acceptable solution.
However, I'm inclined to write: "multiple inputs" at that spot:
Plans that involve appending multiple inputs can therefore achieve...
Using the term "result set" here just feels off, though that is a mostly
uninformed (as to precedent) opinion.
> I'm unsure what exactly this sentence is trying to
> communicate, possibly because I'm only learning Postgres (by reading the
> docs), and I don't understand what partial and non-partial children mean
> from the previous sentences in the context of this section. (Perhaps that
> should also be improved on? Unless it was already explained previously and
> I've merely forgotten, but I couldn't find that phrasing elsewhere in the
> documentation.)
>
Earlier on that page:
"Instead, the parallel portion of the plan must be what is known internally
to the query optimizer as a partial plan; that is, it must be constructed
so that each process that executes the plan will generate only a subset of
the output rows..."
The plan structure is previously defined to be a tree - parent/child. A
partial child is one that is actively executing a partial component of the
overall plan.
The main point being communicated here is that some nodes have multiple
children whose structurally identical result sets (i.e., same columns) are
combined. Those children need not be partial children in order for the
parent node to implement parallelism - rather, two or more of the
non-partial children can operate in parallel with each other, operating on
different parts of the database (in this case separate partitions of a
partitioned table).
It is only when two children need to work on the same area/object that they
need to be partial children that know how share.
David J.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Typo in 15.3.4
2024-07-25 03:47 Typo in 15.3.4 PG Doc comments form <noreply@postgresql.org>
2024-07-25 17:07 ` Re: Typo in 15.3.4 David G. Johnston <david.g.johnston@gmail.com>
@ 2024-07-29 14:00 ` Daniel Gustafsson <daniel@yesql.se>
2024-07-29 14:13 ` Re: Typo in 15.3.4 David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Gustafsson @ 2024-07-29 14:00 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: grantgryczan@gmail.com; pgsql-docs@lists.postgresql.org
> On 25 Jul 2024, at 19:07, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Thu, Jul 25, 2024 at 9:50 AM PG Doc comments form <noreply@postgresql.org <mailto:noreply@postgresql.org>> wrote:
>> The following documentation comment has been logged on the website:
>>
>> Page: https://www.postgresql.org/docs/16/parallel-plans.html
>> Description:
>>
>> In section 15.3.4, I believe "multiple results sets" is a typo for "multiple
>> result sets". It says:
>>
>> > Plans that involve appending multiple results sets can therefore achieve
>> coarse-grained parallelism even when efficient partial plans are not
>> available.
>>
>> It's also possible this should say "multiple results" rather than "multiple
>> result sets".
>
> Good catch, and an acceptable solution.
>
> However, I'm inclined to write: "multiple inputs" at that spot:
>
> Plans that involve appending multiple inputs can therefore achieve...
>
> Using the term "result set" here just feels off, though that is a mostly uninformed (as to precedent) opinion.
I think result sets the correct term since the Append node is combining partial
results made by other parallel nodes. Doing some reading it seems to me that
"results sets" isn't incorrect (though I might have misunderstood the grammar
from not being a native speaker), but I'm still inclined to change since we
consistently use "result sets" in the rest of the documentation.
--
Daniel Gustafsson
=
Attachments:
[application/octet-stream] 0001-doc-Consistent-use-result-set-in-documentation.patch (1.4K, ../../C93E9E77-787D-4AA7-8E45-56C53BDF677A@yesql.se/3-0001-doc-Consistent-use-result-set-in-documentation.patch)
download | inline diff:
From 07bb2c0cc45843ff7e8e5259a207ee51df86acb9 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Mon, 29 Jul 2024 15:44:07 +0200
Subject: [PATCH] doc: Consistent use result set in documentation
We use "result set" in all other places so let's be consistent
across the entire documentation.
Reported-by: grantgryczan@gmail.com
Discussion: https://postgr.es/m/172187924855.915373.15595156724215203822@wrigleys.postgresql.org
---
doc/src/sgml/parallel.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index 590cb385dd..4b3df7c2f8 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -423,7 +423,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
Append</literal> node can have both partial and non-partial child plans.
Non-partial children will be scanned by only a single process, since
scanning them more than once would produce duplicate results. Plans that
- involve appending multiple results sets can therefore achieve
+ involve appending multiple result sets can therefore achieve
coarse-grained parallelism even when efficient partial plans are not
available. For example, consider a query against a partitioned table
that can only be implemented efficiently by using an index that does
--
2.39.3 (Apple Git-146)
=
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Typo in 15.3.4
2024-07-25 03:47 Typo in 15.3.4 PG Doc comments form <noreply@postgresql.org>
2024-07-25 17:07 ` Re: Typo in 15.3.4 David G. Johnston <david.g.johnston@gmail.com>
2024-07-29 14:00 ` Re: Typo in 15.3.4 Daniel Gustafsson <daniel@yesql.se>
@ 2024-07-29 14:13 ` David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: David G. Johnston @ 2024-07-29 14:13 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: grantgryczan@gmail.com; pgsql-docs@lists.postgresql.org
On Mon, Jul 29, 2024 at 7:00 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 25 Jul 2024, at 19:07, David G. Johnston <david.g.johnston@gmail.com>
> wrote:
>
> On Thu, Jul 25, 2024 at 9:50 AM PG Doc comments form <
> noreply@postgresql.org> wrote:
>
>> The following documentation comment has been logged on the website:
>>
>> Page: https://www.postgresql.org/docs/16/parallel-plans.html
>> Description:
>>
>> In section 15.3.4, I believe "multiple results sets" is a typo for
>> "multiple
>> result sets". It says:
>>
>> > Plans that involve appending multiple results sets can therefore achieve
>> coarse-grained parallelism even when efficient partial plans are not
>> available.
>>
>> It's also possible this should say "multiple results" rather than
>> "multiple
>> result sets".
>
>
> Good catch, and an acceptable solution.
>
> However, I'm inclined to write: "multiple inputs" at that spot:
>
> Plans that involve appending multiple inputs can therefore achieve...
>
> Using the term "result set" here just feels off, though that is a mostly
> uninformed (as to precedent) opinion.
>
>
> I think result sets the correct term since the Append node is combining
> partial
> results made by other parallel nodes. Doing some reading it seems to me
> that
> "results sets" isn't incorrect (though I might have misunderstood the
> grammar
> from not being a native speaker), but I'm still inclined to change since we
> consistently use "result sets" in the rest of the documentation.
>
>
Yes, if we leave the term "result set" in place the trailing "s" in the
existing "results" needs to go. I was referring to the term as a whole
when I said it "feels off", not that the spelling of "result sets" is wrong.
David J.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-07-29 14:13 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-25 03:47 Typo in 15.3.4 PG Doc comments form <noreply@postgresql.org>
2024-07-25 17:07 ` David G. Johnston <david.g.johnston@gmail.com>
2024-07-29 14:00 ` Daniel Gustafsson <daniel@yesql.se>
2024-07-29 14:13 ` David G. Johnston <david.g.johnston@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