From: | Theron Luhn <theron(at)luhn(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Understanding Postgres Memory Usage |
Date: | 2016-09-08 23:35:44 |
Message-ID: | CAHYFdT9sb1y_C=Mo1S5WjKfZN9vJQbJ9qU2fw1x2vHydwP6v4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I've done the upgrade to 9.5. Memory bloat has reduced to a more
manageable level. Most workers have an overhead of <20MB, with one outlier
consuming 60MB.
— Theron
On Fri, Aug 26, 2016 at 5:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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 | Venkata B Nagothi | 2016-09-09 00:18:49 | Re: Setup pgpool-II with streaming replication |
Previous Message | David Gibbons | 2016-09-08 20:29:14 | Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2 |