Re: Memory-Bounded Hash Aggregation - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Memory-Bounded Hash Aggregation
Date
Msg-id 20200221202212.ssb2qpmdgrnx52sj@alap3.anarazel.de
Whole thread Raw
In response to Re: Memory-Bounded Hash Aggregation  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Memory-Bounded Hash Aggregation  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Hi,

On 2020-02-19 20:16:36 +0100, Tomas Vondra wrote:
> 3) I wonder if we need to invent new opcodes? Wouldn't it be simpler to
> just add a new flag to the agg_* structs instead? I haven't tried hacking
> this, so maybe it's a silly idea.

New opcodes don't really cost that much - it's a jump table based
dispatch already (yes, it increases the table size slightly, but not by
much). But adding branches inside opcode implementation does add cost -
and we're already bottlenecked by stalls.

I assume code duplication is your primary concern here?

If so, I think the patch 0008 in
https://postgr.es/m/20191023163849.sosqbfs5yenocez3%40alap3.anarazel.de
would improve the situation. I'll try to rebase that onto master.

I'd also like to apply something like 0013 from that thread, I find the
whole curperagg, select_current_set, curaggcontext logic confusing as
hell. I'd so far planned to put this on the backburner until this patch
has been committed, to avoid breaking it. But perhaps that's not the
right call?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: allow running parts of src/tools/msvc/ under not Windows
Next
From: Tom Lane
Date:
Subject: Re: allow running parts of src/tools/msvc/ under not Windows