Re: Default gucs for EXPLAIN

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Vik Fearing <vik(at)postgresfriends(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, 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-06-02 17:54:16
Message-ID: CAKFQuwYphabHO4gcXGbkVr6sVvdTyX1BL7-DvisrUJ5Z4UQw_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 2, 2020 at 10:25 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> > On 5/27/20 7:27 AM, David G. Johnston wrote:
> > >> 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.
> >
> >
> > Yes, the patch handles this case the way you describe. In fact, the
> > patch doesn't (or shouldn't) change any behavior at all.
>
> I think it would have been helpful if an email explaining this idea for
> discussion would have been posted before a patch was generated and
> posted.
>
>
I can see where it would have saved Vik some effort but I'm not seeing how
an email without a patch is better for the rest of us than having a
concrete change to discuss.

At this point, given the original goal of the patch was to try and grease a
smoother path to changing the default for BUFFERS, and that people seem OK
with doing just that without having this patch, I'd say we should just
change the default and forget this patch. There hasn't been any other
demand from our users for this capability and I also doubt that having
BUFFERS on by default is going to bother people.

However, the one default on option, TIMING, also has a nice blurb about why
having it enabled can be problematic and to consider turning it off. Is
there a similar "oh by the way" with BUFFERS that I just haven't come
across that would making having it on cause more problems than it solves?

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hamid Akhtar 2020-06-02 18:38:18 Re: Should we remove a fallback promotion? take 2
Previous Message Robert Haas 2020-06-02 17:45:12 Re: Just for fun: Postgres 20?