From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Justin Pryzby <pryzby@telsasoft.com>, Bruce Momjian <bruce@momjian.us>,
        David Rowley <dgrowleyml@gmail.com>, Jeff Davis <pgsql@j-davis.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        pgsql-hackers@postgresql.org
Subject: Re: Default setting for enable_hashagg_disk
In-reply-to: <20200624183203.cnqcol27ruastit7@development>
References: <20200610021544.GA14879@telsasoft.com>
 <8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com>
 <CA+TgmoagMLfruY4y_40oKLmFFdBRVSGraZsTa5ss9wH546EYhQ@mail.gmail.com>
 <ee1a7be071349b93c01ffb9ef4cf3a6830d9e780.camel@j-davis.com>
 <CA+TgmoY4-zSMFf8XbpO6uRsMX4vNPPLXvtajAZpG3f9eoEyjdA@mail.gmail.com>
 <129c8f1739957589584d9525e1d8782eae3f412f.camel@j-davis.com>
 <CAApHDvqFZikXhAGW=UKZKq1_FzHy+XzmUzAJiNj6RWyTHH4UfA@mail.gmail.com>
 <20200624090628.GA19640@momjian.us> <20200624123843.GX4107@telsasoft.com>
 <2214502.1593019796@sss.pgh.pa.us>
 <20200624183203.cnqcol27ruastit7@development>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Wed, 24 Jun 2020 20:32:03 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2217144.1593024050.1@sss.pgh.pa.us>
Date: Wed, 24 Jun 2020 14:40:50 -0400
Message-ID: <2217145.1593024050@sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Wed, Jun 24, 2020 at 01:29:56PM -0400, Tom Lane wrote:
>> If we feel we need something to let people have the v12 behavior
>> back, let's have
>> (1) enable_hashagg on/off --- controls planner, same as it ever was
>> (2) enable_hashagg_spill on/off --- controls executor by disabling spill

> What if a user specifies
>    enable_hashagg = on
>    enable_hashagg_spill = off

It would probably be reasonable for the planner to behave as it did
pre-v13, that is not choose hashagg if it estimates that work_mem
would be exceeded.  (So, okay, that means enable_hashagg_spill
affects both planner and executor ... but ISTM it's just one
behavior not two.)

			regards, tom lane