From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: Peter Geoghegan <pg@bowt.ie>, Alvaro Herrera <alvherre@2ndquadrant.com>,
        David Rowley <dgrowleyml@gmail.com>,
        Stephen Frost <sfrost@snowman.net>,
 Andres Freund <andres@anarazel.de>,
        Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>,
        Justin Pryzby <pryzby@telsasoft.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Default setting for enable_hashagg_disk
In-reply-to: <6d0aba397625df79bdc3ca85adc11b9e48ecb0da.camel@j-davis.com>
References: <5cf74833a830e76cc7cc7506aa77bd6ab0c94f4c.camel@j-davis.com>
 <20200713164736.GA25726@alvherre.pgsql>
 <CAH2-WzmaJG4QYHq5LR+ZXEf1JMVcTzT9pEOeMFg0uuGXYDvgzQ@mail.gmail.com>
 <9e4a4cffe3eee0543e5b94c90821d39e03b81d29.camel@j-davis.com>
 <CAH2-Wz=qBF1QyXKdB6YNV993WpQ0wj-x4h8r9yjYUwQRCMkLjA@mail.gmail.com>
 <6d0aba397625df79bdc3ca85adc11b9e48ecb0da.camel@j-davis.com>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Sat, 18 Jul 2020 11:16:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4118679.1595097043.1@sss.pgh.pa.us>
Date: Sat, 18 Jul 2020 14:30:43 -0400
Message-ID: <4118680.1595097043@sss.pgh.pa.us>
Precedence: bulk

Jeff Davis <pgsql@j-davis.com> writes:
> On Fri, 2020-07-17 at 18:38 -0700, Peter Geoghegan wrote:
>> There is also the separate question of what to do about the
>> hashagg_avoid_disk_plan GUC (this is a separate open item that
>> requires a separate resolution). Tom leans slightly towards removing
>> it now. Is your position about the same as before?

> Yes, I think we should have that GUC (hashagg_avoid_disk_plan) for at
> least one release.

You'e being optimistic about it being possible to remove a GUC once
we ship it.  That seems to be a hard sell most of the time.

I'm honestly a bit baffled about the level of fear being expressed
around this feature.  We have *frequently* made changes that would
change query plans, perhaps not 100.00% for the better, and never
before have we had this kind of bikeshedding about whether it was
necessary to be able to turn it off.  I think the entire discussion
is way out ahead of any field evidence that we need such a knob.
In the absence of evidence, our default position ought to be to
keep it simple, not to accumulate backwards-compatibility kluges.

(The only reason I'm in favor of heap_mem[_multiplier] is that it
seems like it might be possible to use it to get *better* plans
than before.  I do not see it as a backwards-compatibility knob.)

			regards, tom lane