From 94eec79633f284488de69e253857e44aad10c730 Mon Sep 17 00:00:00 2001 From: Daniel Gustafsson Date: Mon, 2 Sep 2024 18:36:57 +0200 Subject: [PATCH] doc: Consistently 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 590cb385ddf..4b3df7c2f8d 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 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