| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Theron Luhn <theron(at)luhn(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Understanding Postgres Memory Usage |
| Date: | 2016-08-26 12:41:02 |
| Message-ID: | 25527.1472215262@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Theron Luhn <theron(at)luhn(dot)com> writes:
> Okay, I got a semi-reproducible test case:
> https://gist.github.com/luhn/2b35a9b31255e3a6a2e6a06d1213dfc9
> The one caveat is that the memory rise only happens when using a
> HashAggregate query plan (included in the gist), which I can't find a way
> to get Postgres to reliably use.
OK, I can reproduce some memory bloat in 9.3, but not in 9.5 and up.
I believe this was fixed by commit b419865a8, which reduced the overhead
of running a lot of instances of array_agg() concurrently in a HashAgg
plan. I think your options are to live with it or upgrade. Or I guess
you could turn off enable_hashagg when using array_agg() plus GROUP BY,
though you'd want to remember to undo that whenever you do upgrade.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Farber | 2016-08-26 15:20:37 | a column definition list is required for functions returning "record" |
| Previous Message | Theron Luhn | 2016-08-26 02:44:12 | Re: Understanding Postgres Memory Usage |