Message-ID: <bfec56be9bd5e245da4e733197af9b485bf40362.camel@j-davis.com>
Subject: Re: Default setting for enable_hashagg_disk
From: Jeff Davis <pgsql@j-davis.com>
To: Justin Pryzby <pryzby@telsasoft.com>, Melanie Plageman
	 <melanieplageman@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tomas Vondra
	 <tomas.vondra@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: Thu, 11 Jun 2020 13:22:57 -0700
In-Reply-To: <8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com>
References: <9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com>
	 <20200407223900.GT2228@telsasoft.com>
	 <20200409114855.h4hh7e2wt77p56sv@development>
	 <CA+Tgmoa74xaiZTdLeQ_aiPE7-eJb_Pdkc_K_hv95PdaDjZnxKQ@mail.gmail.com>
	 <6292f5a766198d5745eb8cc17ac736366056671d.camel@j-davis.com>
	 <CAAKRu_aisiENMsPM2gC4oUY1hHG3yrCwY-fXUg22C6_MJUwQdA@mail.gmail.com>
	 <20200610021544.GA14879@telsasoft.com>
	 <8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2020-06-10 at 11:39 -0700, Jeff Davis wrote:
> 1. Testing the spilling of hashed grouping sets: I'm inclined to just
> get rid of enable_groupingsets_hash_disk and use Melanie's stats-
> hacking approach instead.

Fixed in 92c58fd9.

> think the names you suggested quite fit, but the idea to use a more
> interesting GUC value might help express the behavior. Perhaps making
> enable_hashagg a ternary "enable_hashagg=on|off|avoid_disk"? The word
> "reject" is too definite for the planner, which is working with
> imperfect information.

I renamed enable_hashagg_disk to hashagg_avoid_disk_plan, which I think
satisfies the concerns raised here. Also in 92c58fd9.

There is still the original topic of this thread, which is whether we
need to change the default value of this GUC, or penalize disk-based
HashAgg in some way, to be more conservative about plan changes in v13.
I think we can wait a little longer to make a decision there.

Regards,
	Jeff Davis