mirror of
https://github.com/postgres/postgres.git
synced 2025-05-02 11:44:50 +03: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
|
||||
index. Currently, parallel index scans are supported only for
|
||||
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.
|
||||
The results of a parallel btree scan are returned in sorted order
|
||||
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
|
||||
coarse-grained parallelism even when efficient partial plans are not
|
||||
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
|
||||
Append</literal> of regular <literal>Index Scan</literal> plans; each
|
||||
individual index scan would have to be executed to completion by a single
|
||||
|
Loading…
x
Reference in New Issue
Block a user