You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Determine whether it's safe to attempt a parallel plan for a query.
Commit924bcf4 introduced a frameworkfor parallel computation in PostgreSQL that makes most but not allbuilt-in functions safe to execute in parallel mode. In order to haveparallel query, we'll need to be able to determine whether that querycontains functions (either built-in or user-defined) that cannot besafely executed in parallel mode. This requires those functions to belabeled, so this patch introduces an infrastructure for that. Somefunctions currently labeled as safe may need to be revised depending onhow pending issues related to heavyweight locking under paralllelismare resolved.Parallel plans can't be used except for the case where the query willrun to completion. If portal execution were suspended, the parallelmode restrictions would need to remain in effect during that time, butthat might make other queries fail. Therefore, this patch introducesa framework that enables consideration of parallel plans only when itis known that the plan will be run to completion. This probably needssome refinement; for example, at bind time, we do not know whether aquery run via the extended protocol will be execution to completion orrun with a limited fetch count. Having the client indicate itsintentions at bind time would constitute a wire protocol break. Somecontexts in which parallel mode would be safe are not adjusted by thispatch; the default is not to try parallel plans except from call sitesthat have been updated to say that such plans are OK.This commit doesn't introduce any parallel paths or plans; it justprovides a way to determine whether they could potentially be used.I'm committing it on the theory that the remaining parallel sequentialscan patches will also get committed to this release, hopefully in thenot-too-distant future.Robert Haas and Amit Kapila. Reviewed (in earlier versions) by NoahMisch.
| SET <replaceable class="parameter">configuration_parameter</replaceable> { TO <replaceable class="parameter">value</replaceable> | = <replaceable class="parameter">value</replaceable> | FROM CURRENT }
@@ -411,6 +412,43 @@ CREATE [ OR REPLACE ] FUNCTION
411
412
</listitem>
412
413
</varlistentry>
413
414
415
+
<varlistentry>
416
+
<term><literal>PARALLEL</literal></term>
417
+
418
+
<listitem>
419
+
<para><literal>PARALLEL UNSAFE</literal> indicates that the function
420
+
can't be executed in parallel mode and the presence of such a
421
+
function in an SQL statement forces a serial execution plan. This is
422
+
the default. <literal>PARALLEL RESTRICTED</literal> indicates that
423
+
the function can be executed in parallel mode, but the execution is
424
+
restricted to parallel group leader. <literal>PARALLEL SAFE</literal>
425
+
indicates that the function is safe to run in parallel mode without
426
+
restriction.
427
+
</para>
428
+
429
+
<para>
430
+
Functions should be labeled parallel unsafe if they modify any database
431
+
state, or if they make changes to the transaction such as using
432
+
sub-transactions, or if they access sequences or attempt to make
433
+
persistent changes to settings (e.g. <literal>setval</>). They should
434
+
be labeled as parallel restricted if they access temporary tables,
435
+
client connection state, cursors, prepared statements, or miscellaneous
436
+
backend-local state which the system cannot synchronize in parallel mode
437
+
(e.g. <literal>setseed</> cannot be executed other than by the group
438
+
leader because a change made by another process would not be reflected
439
+
in the leader). In general, if a function is labeled as being safe when
440
+
it is restricted or unsafe, or if it is labeled as being restricted when
441
+
it is in fact unsafe, it may throw errors or produce wrong answers
442
+
when used in a parallel query. C-language functions could in theory
443
+
exhibit totally undefined behavior if mislabeled, since there is no way
444
+
for the system to protect itself against arbitrary C code, but in most
445
+
likely cases the result will be no worse than for any other function.
446
+
If in doubt, functions should be labeled as <literal>UNSAFE</>, which is