| From: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(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:57:40 |
| Message-ID: | 8be2893b-d78c-c440-2f95-728e1b11f4d9@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/12/22 00:50, David Rowley wrote:
>
> 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.
Makes sense, also would definitely rule out any brute force algorithms. Good point to know
> 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.
I am not sure if I understand this, does it means at given time, do allocation for only one distinct aggregate
instead of all, in case of multiple aggregates using distinct?
--
Regards,
Ankit Kumar Pandey
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-12-03 20:16:17 | Re: Generate pg_stat_get_* functions with Macros |
| Previous Message | David Rowley | 2022-12-03 19:20:35 | Re: Questions regarding distinct operation implementation |