database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Introduce a new GUC force_parallel_mode for testing purposes.

Browse Source 
When force_parallel_mode = true, we enable the parallel mode restrictions
for all queries for which this is believed to be safe.  For the subset of
those queries believed to be safe to run entirely within a worker, we spin
up a worker and run the query there instead of running it in the
original process.  When force_parallel_mode = regress, make additional
changes to allow the regression tests to run cleanly even though parallel
workers have been injected under the hood.

Taken together, this facilitates both better user testing and better
regression testing of the parallelism code.

Robert Haas, with help from Amit Kapila and Rushabh Lathia.
This commit is contained in:
Robert Haas
2016-02-07 11:39:22 -05:00
parent a1c1af2a1f
commit 7c944bd903
13 changed files with 163 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
doc/src/sgml/config.sgml
View File

@ -3802,6 +3802,51 @@ SELECT * FROM parent WHERE key = 2400;
</listitem>
</varlistentry>
<varlistentry id="guc-force-parallel-mode" xreflabel="force_parallel_mode">
<term><varname>force_parallel_mode</varname> (<type>enum</type>)
<indexterm>
<primary><varname>force_parallel_mode</> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Allows the use of parallel queries for testing purposes even in cases
where no performance benefit is expected.
The allowed values of <varname>force_parallel_mode</> are
<literal>off</> (use parallel mode only when it is expected to improve
performance), <literal>on</> (force parallel query for all queries
for which it is thought to be safe), and <literal>regress</> (like
on, but with additional behavior changes to facilitate automated
regression testing).
</para>
<para>
More specifically, setting this value to <literal>on</> will add
a <literal>Gather</> node to the top of any query plan for which this
appears to be safe, so that the query runs inside of a parallel worker.
Even when a parallel worker is not available or cannot be used,
operations such as starting a subtransaction that would be prohibited
in a parallel query context will be prohibited unless the planner
believes that this will cause the query to fail. If failures or
unexpected results occur when this option is set, some functions used
by the query may need to be marked <literal>PARALLEL UNSAFE</literal>
(or, possibly, <literal>PARALLEL RESTRICTED</literal>).
</para>
<para>
Setting this value to <literal>regress</> has all of the same effects
as setting it to <literal>on</> plus some additional effect that are
intended to facilitate automated regression testing. Normally,
messages from a parallel worker are prefixed with a context line,
but a setting of <literal>regress</> suppresses this to guarantee
reproducible results. Also, the <literal>Gather</> nodes added to
plans by this setting are hidden from the <literal>EXPLAIN</> output
so that the output matches what would be obtained if this setting
were turned <literal>off</>.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>