From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Questions regarding distinct operation implementation |
Date: | 2022-12-03 19:20:35 |
Message-ID: | CAApHDvp0=0jGdbaMMpdE2+LJF1r+qwCQbRhNHJ3okGCi3ESC9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 3 Dec 2022 at 20:36, Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> wrote:
> Shouldn't this be an acceptable tradeoff if someone wants to perform
> extra operation in plain old aggregates? Although I am not sure how much
> this extra memory and compute usage is considered as acceptable.
We do our best to ensure that a given executor node never uses more
than work_mem. Certainly, we still do have nodes that can exceed this
by a long way. It would be unlikely that we'd accept anything new
that could do this. Since nodeWindowAgg.c already can use up to
work_mem for the tuplestore, it does not seem unreasonable that if
there is a DISTINCT aggregate that you could use 50% of work_mem for
each, that is, providing you can code it in such a way that you only
allocate one of these at once, i.e not allocate one per DISTINCT
aggregate all at once.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Ankit Kumar Pandey | 2022-12-03 19:57:40 | Re: Questions regarding distinct operation implementation |
Previous Message | Andres Freund | 2022-12-03 18:17:22 | Re: Replace PROC_QUEUE / SHM_QUEUE with ilist.h |