Re: Default gucs for EXPLAIN

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Vik Fearing <vik(at)postgresfriends(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Default gucs for EXPLAIN
Date: 2020-05-27 05:27:52
Message-ID: CAKFQuwZ3x_d6_SkzxR+s2XYeB-iY_TeN=EOL=5Ud7dyT2DWmCA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, May 26, 2020, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Tue, 26 May 2020 at 23:59, Vik Fearing <vik(at)postgresfriends(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2020-05-27 05:29:39 Re: segmentation fault using currtid and partitioned tables
Previous Message David Rowley 2020-05-27 05:10:00 Re: Default gucs for EXPLAIN