From: Bruce Momjian <bruce@momjian.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Default setting for enable_hashagg_disk
Date: Thu, 25 Jun 2020 14:25:12 -0400
Message-ID: <20200625182512.GC12486@momjian.us> (raw)
In-Reply-To: <8fd82a9e6c00b73191d18940b2da6a94a30477af.camel@j-davis.com>
References: <CAApHDvqFZikXhAGW=UKZKq1_FzHy+XzmUzAJiNj6RWyTHH4UfA@mail.gmail.com>
<20200624090628.GA19640@momjian.us>
<CAApHDvrcfOOjRmO5EZk_a_GKd-RUGG+2FTM=Sr4jZUbHaBJqjA@mail.gmail.com>
<20200624171203.GB17842@momjian.us>
<20200624191900.t4sbfk236gndwoa3@alap3.anarazel.de>
<20200624231810.GB13627@momjian.us>
<20200624233837.GA21436@momjian.us>
<CA+TgmoYi_03kpoukBzVrsVeNWY_BcLOFjUD8vTtt-fNmNy5NCA@mail.gmail.com>
<20200625171756.GB12486@momjian.us>
<8fd82a9e6c00b73191d18940b2da6a94a30477af.camel@j-davis.com>
On Thu, Jun 25, 2020 at 11:02:30AM -0700, Jeff Davis wrote:
> If we have the GUCs there, then at least if someone comes to the
> mailing list with a problem, we can offer them a temporary solution,
> and have time to try to avoid the problem in a future release (tweaking
> estimates, cost model, defaults, etc.).
>
> One idea is to have undocumented GUCs. That way we don't have to
> support them forever, and we are more likely to hear problem reports.
Uh, our track record of adding GUCs just in case is not good, and
removing them is even harder. Undocumented sounds interesting but then
how do we even document when we remove it? I don't think we want to go
there. Oracle has done that, and I don't think the user experience is
good.
Maybe we should just continue though beta, add an incompatibility item
to the PG 13 release notes, and see what feedback we get. We know
increasing work_mem gets us the exceed work_mem behavior, but that
affects other nodes too, and I can't think of a way to avoid if spill is
predicted except to disable hash agg for that query.
I am still trying to get my head around why the spill is going to be so
much work to adjust for hash agg than our other spillable nodes. What
are people doing for those cases already? Do we have an real-world
queries that are a problem in PG 13 for this?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
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-docs@postgresql.org
Cc: bruce@momjian.us, pgsql@j-davis.com, robertmhaas@gmail.com, andres@anarazel.de, dgrowleyml@gmail.com, pryzby@telsasoft.com, melanieplageman@gmail.com, tomas.vondra@2ndquadrant.com, pgsql-hackers@postgresql.org
Subject: Re: Default setting for enable_hashagg_disk
In-Reply-To: <20200625182512.GC12486@momjian.us>
* 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