On Tue, Feb 15, 2022 at 8:17 AM Justin Pryzby wrote:
> The only reason not to is that a single-node hash-aggregate plan will now use
> 2x work_mem. Which won't make sense to someone who doesn't deal with
> complicated plans (and who doesn't know that work_mem is per-node and can be
> used
On Mon, Feb 14, 2022 at 10:32:43PM -0800, Peter Geoghegan wrote:
> On Wed, Jan 19, 2022 at 11:32 AM John Naylor
> wrote:
> > I don't have anything really profound to say here, but in the last
> > year I did on a couple occasions recommend clients to raise
> > hash_mem_multiplier to 2.0 to fix
On Wed, Jan 19, 2022 at 11:32 AM John Naylor
wrote:
> I don't have anything really profound to say here, but in the last
> year I did on a couple occasions recommend clients to raise
> hash_mem_multiplier to 2.0 to fix performance problems.
I would like to push ahead with an increase in the
On Sun, Jan 16, 2022 at 7:28 PM Peter Geoghegan wrote:
>
> The current hash_mem_multiplier default is 1.0, which is a fairly
> conservative default: it preserves the historic behavior, which is
> that hash-based executor nodes receive the same work_mem budget as
> sort-based nodes. I propose that
The current hash_mem_multiplier default is 1.0, which is a fairly
conservative default: it preserves the historic behavior, which is
that hash-based executor nodes receive the same work_mem budget as
sort-based nodes. I propose that the default be increased to 2.0 for
Postgres 15.
Arguments in
