| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Big performance slowdown from 11.2 to 13.3 |
| Date: | 2021-07-22 17:04:31 |
| Message-ID: | CAH2-Wzm9RuBzbq-h15TXTk7RQ_A8JfMk4kdGn_pQFuMsSPBJ+A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Jul 22, 2021 at 9:53 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I suspect David's theory about hash_agg_set_limits()'s ngroup limit is
> correct. It certainly seems like a good starting point.
I also suspect that if Laurent set work_mem and/or hash_mem_multiplier
*extremely* aggressively, then eventually the hash agg would be
in-memory. And without actually using all that much memory.
I'm not suggesting that that is a sensible resolution to Laurent's
complaint. I'm just pointing out that it's probably not fundamentally
impossible to make the hash agg avoid spilling through tuning these
GUCs. At least I see no evidence of that right now.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-07-22 17:11:33 | Re: Big performance slowdown from 11.2 to 13.3 |
| Previous Message | Tom Lane | 2021-07-22 16:56:53 | Re: Big performance slowdown from 11.2 to 13.3 |