Re: Questions regarding distinct operation implementation

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

In response to

Responses

Browse pgsql-hackers by date

  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