From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] force_parallel_mode and GUC categories
Date: Tue, 13 Apr 2021 07:31:39 -0500
Message-ID: <20210413123139.GE6091@telsasoft.com> (raw)
In-Reply-To: <YHVJfw2YN5/oGAcQ@paquier.xyz>
References: <3972636.1617464359@sss.pgh.pa.us>
<20210403154114.GJ6592@telsasoft.com>
<20210403154336.GG29125@momjian.us>
<20210404012546.GK6592@telsasoft.com>
<YG+y/eJErKPDUhiS@paquier.xyz>
<20210409031718.GO6592@telsasoft.com>
<20210409113928.GA12919@momjian.us>
<YHPUHdXuCzMIROf9@paquier.xyz>
<2746080.1618206052@sss.pgh.pa.us>
<YHVJfw2YN5/oGAcQ@paquier.xyz>
On Tue, Apr 13, 2021 at 04:34:23PM +0900, Michael Paquier wrote:
> On Mon, Apr 12, 2021 at 01:40:52AM -0400, Tom Lane wrote:
> >> - Should we make more general the description of the developer options
> >> in the docs?
> >
> > Perhaps ... what did you have in mind?
>
> The first sentence of the page now says that:
> "The following parameters are intended for work on the PostgreSQL
> source code, and in some cases to assist with recovery of severely
> damaged databases."
>
> That does not stick with force_parallel_mode IMO. Maybe:
Good point.
--
Justin
Attachments:
[text/x-diff] v3-0001-track_activity_query_size-is-STATS_COLLECTOR-cate.patch (877B, ../20210413123139.GE6091@telsasoft.com/2-v3-0001-track_activity_query_size-is-STATS_COLLECTOR-cate.patch)
download | inline diff:
From b5355f3384df1aab87e4cb89afcf4d9703c14bdb Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 3 Apr 2021 19:06:37 -0500
Subject: [PATCH v3 1/3] track_activity_query_size is STATS_COLLECTOR category
Not Resource Usage / Memory, as since 995fb7420
---
src/backend/utils/misc/guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.cindex d0a51b507d..e65d62e71d 100644--- a/src/backend/utils/misc/guc.c+++ b/src/backend/utils/misc/guc.c@@ -3506,7 +3506,7 @@ static struct config_int ConfigureNamesInt[] =
},
{
- {"track_activity_query_size", PGC_POSTMASTER, RESOURCES_MEM,+ {"track_activity_query_size", PGC_POSTMASTER, STATS_COLLECTOR,
gettext_noop("Sets the size reserved for pg_stat_activity.query, in bytes."),
NULL,
GUC_UNIT_BYTE
--
2.17.0
[text/x-diff] v3-0002-track_commit_timestamp-is-REPLICATION_SENDING.patch (853B, ../20210413123139.GE6091@telsasoft.com/3-v3-0002-track_commit_timestamp-is-REPLICATION_SENDING.patch)
download | inline diff:
From b491b4520f157fb1328925f500f15fe2ef8e457c Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 3 Apr 2021 19:17:03 -0500
Subject: [PATCH v3 2/3] track_commit_timestamp is REPLICATION_SENDING
If I'm not wrong, this was missed at 4bd8ed31b
---
src/backend/utils/misc/guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.cindex e65d62e71d..a3c2ebbc53 100644--- a/src/backend/utils/misc/guc.c+++ b/src/backend/utils/misc/guc.c@@ -1188,7 +1188,7 @@ static struct config_bool ConfigureNamesBool[] =
check_bonjour, NULL, NULL
},
{
- {"track_commit_timestamp", PGC_POSTMASTER, REPLICATION,+ {"track_commit_timestamp", PGC_POSTMASTER, REPLICATION_SENDING,
gettext_noop("Collects transaction commit time."),
NULL
},
--
2.17.0
[text/x-diff] v3-0003-Change-force_parallel_mode-to-a-DEVELOPER-GUC-and.patch (8.0K, ../20210413123139.GE6091@telsasoft.com/4-v3-0003-Change-force_parallel_mode-to-a-DEVELOPER-GUC-and.patch)
download | inline diff:
From e9b556f2bc75dc8350759e4b32e588325086218e Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 3 Apr 2021 19:24:50 -0500
Subject: [PATCH v3 3/3] Change force_parallel_mode to a DEVELOPER GUC, and
remove it from sample config..
..to discourage users from changing this option in hopes that it'll make their
queries faster, but without reading the documentation or understanding what it
does.
---
doc/src/sgml/config.sgml | 96 ++++++++++---------
src/backend/utils/misc/guc.c | 2 +-
src/backend/utils/misc/postgresql.conf.sample | 1 -
3 files changed, 50 insertions(+), 49 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgmlindex f749fe9ce7..a7350c6ddc 100644--- a/doc/src/sgml/config.sgml+++ b/doc/src/sgml/config.sgml@@ -5912,51 +5912,6 @@ 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</varname> 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</varname> are- <literal>off</literal> (use parallel mode only when it is expected to improve- performance), <literal>on</literal> (force parallel query for all queries- for which it is thought to be safe), and <literal>regress</literal> (like- <literal>on</literal>, but with additional behavior changes as explained- below).- </para>-- <para>- More specifically, setting this value to <literal>on</literal> will add- a <literal>Gather</literal> 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</literal> has all of the same effects- as setting it to <literal>on</literal> plus some additional effects that are- intended to facilitate automated regression testing. Normally,- messages from a parallel worker include a context line indicating that,- but a setting of <literal>regress</literal> suppresses this line so that the- output is the same as in non-parallel execution. Also,- the <literal>Gather</literal> nodes added to plans by this setting are hidden- in <literal>EXPLAIN</literal> output so that the output matches what- would be obtained if this setting were turned <literal>off</literal>.- </para>- </listitem>- </varlistentry>-
<varlistentry id="guc-plan-cache_mode" xreflabel="plan_cache_mode">
<term><varname>plan_cache_mode</varname> (<type>enum</type>)
<indexterm>
@@ -10374,8 +10329,10 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
<title>Developer Options</title>
<para>
- The following parameters are intended for work on the- <productname>PostgreSQL</productname> source code, and in some cases+ The following parameters are intended for development with+ <productname>PostgreSQL</productname>. Some of them are useful while+ writing SQL queries, some of them are useful when+ working on the source code of PostgreSQL itself, and
to assist with recovery of severely damaged databases. There
should be no reason to use them on a production database.
As such, they have been excluded from the sample
@@ -10464,6 +10421,51 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
</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</varname> 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</varname> are+ <literal>off</literal> (use parallel mode only when it is expected to improve+ performance), <literal>on</literal> (force parallel query for all queries+ for which it is thought to be safe), and <literal>regress</literal> (like+ <literal>on</literal>, but with additional behavior changes as explained+ below).+ </para>++ <para>+ More specifically, setting this value to <literal>on</literal> will add+ a <literal>Gather</literal> 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</literal> has all of the same effects+ as setting it to <literal>on</literal> plus some additional effects that are+ intended to facilitate automated regression testing. Normally,+ messages from a parallel worker include a context line indicating that,+ but a setting of <literal>regress</literal> suppresses this line so that the+ output is the same as in non-parallel execution. Also,+ the <literal>Gather</literal> nodes added to plans by this setting are hidden+ in <literal>EXPLAIN</literal> output so that the output matches what+ would be obtained if this setting were turned <literal>off</literal>.+ </para>+ </listitem>+ </varlistentry>+
<varlistentry id="guc-ignore-system-indexes" xreflabel="ignore_system_indexes">
<term><varname>ignore_system_indexes</varname> (<type>boolean</type>)
<indexterm>
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.cindex a3c2ebbc53..b8738561e6 100644--- a/src/backend/utils/misc/guc.c+++ b/src/backend/utils/misc/guc.c@@ -4922,7 +4922,7 @@ static struct config_enum ConfigureNamesEnum[] =
},
{
- {"force_parallel_mode", PGC_USERSET, QUERY_TUNING_OTHER,+ {"force_parallel_mode", PGC_USERSET, DEVELOPER_OPTIONS,
gettext_noop("Forces use of parallel query facilities."),
gettext_noop("If possible, run query using a parallel worker and with parallel restrictions."),
GUC_EXPLAIN
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sampleindex 2f6dd014a8..0f7f49b949 100644--- a/src/backend/utils/misc/postgresql.conf.sample+++ b/src/backend/utils/misc/postgresql.conf.sample@@ -421,7 +421,6 @@
#from_collapse_limit = 8
#join_collapse_limit = 8 # 1 disables collapsing of explicit
# JOIN clauses
-#force_parallel_mode = off
#jit = on # allow JIT compilation
#plan_cache_mode = auto # auto, force_generic_plan or
# force_custom_plan
--
2.17.0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, michael@paquier.xyz, tgl@sss.pgh.pa.us, bruce@momjian.us, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] force_parallel_mode and GUC categories
In-Reply-To: <20210413123139.GE6091@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox