mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-23 07:00:40 +02:00
Fix typos in parallel query docs.
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:
parent
adc9cb6f26
commit
a8474d8630
@ -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
|
||||||
|
Loading…
Reference in New Issue
Block a user