@@ -134,12 +134,12 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
134
134
135
135
<itemizedlist>
136
136
<listitem>
137
- <para>
137
+ <para>
138
138
The query writes any data or locks any database rows. If a query
139
139
contains a data-modifying operation either at the top level or within
140
140
a CTE, no parallel plans for that query will be generated. This is a
141
141
limitation of the current implementation which could be lifted in a
142
- future release.
142
+ future release.
143
143
</para>
144
144
</listitem>
145
145
@@ -153,7 +153,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
153
153
<literal>FOR x IN query LOOP .. END LOOP</literal> will never use a
154
154
parallel plan, because the parallel query system is unable to verify
155
155
that the code in the loop is safe to execute while parallel query is
156
- active.
156
+ active.
157
157
</para>
158
158
</listitem>
159
159
@@ -174,7 +174,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
174
174
query itself, that query will never use a parallel plan. This is a
175
175
limitation of the current implementation, but it may not be desirable
176
176
to remove this limitation, since it could result in a single query
177
- using a very large number of processes.
177
+ using a very large number of processes.
178
178
</para>
179
179
</listitem>
180
180
@@ -197,23 +197,23 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
197
197
198
198
<itemizedlist>
199
199
<listitem>
200
- <para>
200
+ <para>
201
201
No background workers can be obtained because of the limitation that
202
202
the total number of background workers cannot exceed
203
203
<xref linkend="guc-max-worker-processes">.
204
204
</para>
205
205
</listitem>
206
206
207
207
<listitem>
208
- <para>
208
+ <para>
209
209
No background workers can be obtained because of the limitation that
210
210
the total number of background workers launched for purposes of
211
211
parallel query cannot exceed <xref linkend="guc-max-parallel-workers">.
212
212
</para>
213
213
</listitem>
214
214
215
215
<listitem>
216
- <para>
216
+ <para>
217
217
The client sends an Execute message with a non-zero fetch count.
218
218
See the discussion of the
219
219
<link linkend="protocol-flow-ext-query">extended query protocol</link>.
@@ -228,7 +228,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
228
228
</listitem>
229
229
230
230
<listitem>
231
- <para>
231
+ <para>
232
232
A prepared statement is executed using a <literal>CREATE TABLE .. AS
233
233
EXECUTE ..</literal> statement. This construct converts what otherwise
234
234
would have been a read-only operation into a read-write operation,
@@ -237,7 +237,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
237
237
</listitem>
238
238
239
239
<listitem>
240
- <para>
240
+ <para>
241
241
The transaction isolation level is serializable. This situation
242
242
does not normally arise, because parallel query plans are not
243
243
generated when the transaction isolation level is serializable.
@@ -467,15 +467,15 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
467
467
transaction. If you write a function which does this, and this behavior
468
468
difference is important to you, mark such functions as
469
469
<literal>PARALLEL RESTRICTED</literal>
470
- to ensure that they execute only in the leader.
470
+ to ensure that they execute only in the leader.
471
471
</para>
472
472
473
473
<para>
474
474
Note that the query planner does not consider deferring the evaluation of
475
475
parallel-restricted functions or aggregates involved in the query in
476
476
order to obtain a superior plan. So, for example, if a <literal>WHERE</>
477
477
clause applied to a particular table is parallel restricted, the query
478
- planner will not consider placing the scan of that table below a
478
+ planner will not consider placing the scan of that table below a
479
479
<literal>Gather</> node. In some cases, it would be
480
480
possible (and perhaps even efficient) to include the scan of that table in
481
481
the parallel portion of the query and defer the evaluation of the
0 commit comments