Re: Default gucs for EXPLAIN - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Default gucs for EXPLAIN
Date
Msg-id CAKFQuwZ3x_d6_SkzxR+s2XYeB-iY_TeN=EOL=5Ud7dyT2DWmCA@mail.gmail.com
Whole thread Raw
In response to Re: Default gucs for EXPLAIN  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Default gucs for EXPLAIN  (Vik Fearing <vik@postgresfriends.org>)
List pgsql-hackers
On Tuesday, May 26, 2020, David Rowley <dgrowleyml@gmail.com> wrote:
On Tue, 26 May 2020 at 23:59, Vik Fearing <vik@postgresfriends.org> wrote:
> Are you saying we should have all new EXPLAIN options off forever into
> the future because apps won't know about the new data?  I guess we
> should also not ever introduce new plan nodes because those won't be
> known either.

Another argument against this is that it creates dependency among the
new GUCs. Many of the options are not compatible with each other. e.g.

postgres=# explain (timing on) select 1;
ERROR:  EXPLAIN option TIMING requires ANALYZE

Would you propose we just error out in that case, or should we
silently enable the required option, or disable the conflicting
option?


The same thing we do today...ignore options that require analyze if analyze is not specified.  There are no other options documented that are dependent with options besides than analyze.  The docs say timing defaults to on, its only when explicitly specified instead of being treated as a default that the user message appears.  All the GUCs are doing is changing the default.

David J.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Default gucs for EXPLAIN
Next
From: Jaime Casanova
Date:
Subject: Re: segmentation fault using currtid and partitioned tables