database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-02 11:44:50 +03:00
Code

Fix typos in parallel query docs.

Browse Source 
Reported-by: Jon Jensen
Author: Jon Jensen
Reviewed-by: Amit Kapila and Robert Haas
Backpatch-through: 10
Discussion: https://postgr.es/m/nycvar.YSQ.7.76.1912301807510.9899@ybpnyubfg
This commit is contained in:
Amit Kapila 2020-01-03 10:52:46 +05:30
parent adc9cb6f26
commit a8474d8630
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/sgml/parallel.sgml
View File

@ -302,7 +302,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
scan</emphasis>, the cooperating processes take turns reading data from the scan</emphasis>, the cooperating processes take turns reading data from the
index. Currently, parallel index scans are supported only for index. Currently, parallel index scans are supported only for
btree indexes. Each process will claim a single index block and will btree indexes. Each process will claim a single index block and will
scan and return all tuples referenced by that block; other process can scan and return all tuples referenced by that block; other processes can
at the same time be returning tuples from a different index block. at the same time be returning tuples from a different index block.
The results of a parallel btree scan are returned in sorted order The results of a parallel btree scan are returned in sorted order
within each worker process. within each worker process.
@ -435,7 +435,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
involve appending multiple results sets can therefore achieve involve appending multiple results sets can therefore achieve
coarse-grained parallelism even when efficient partial plans are not coarse-grained parallelism even when efficient partial plans are not
available. For example, consider a query against a partitioned table available. For example, consider a query against a partitioned table
which can be only be implemented efficiently by using an index that does which can only be implemented efficiently by using an index that does
not support parallel scans. The planner might choose a <literal>Parallel not support parallel scans. The planner might choose a <literal>Parallel
Append</literal> of regular <literal>Index Scan</literal> plans; each Append</literal> of regular <literal>Index Scan</literal> plans; each
individual index scan would have to be executed to completion by a single individual index scan would have to be executed to completion by a single