Re: Memory-Bounded Hash Aggregation

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Memory-Bounded Hash Aggregation
Дата
Msg-id 20200221202212.ssb2qpmdgrnx52sj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Memory-Bounded Hash Aggregation  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Memory-Bounded Hash Aggregation  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: allow running parts of src/tools/msvc/ under not Windows
Следующее
От: Tom Lane
Дата:
Сообщение: Re: allow running parts of src/tools/msvc/ under not Windows