| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Justin Graf <justin(at)magwerks(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org, anton200(at)gmail(dot)com |
| Subject: | Re: How exactly PostgreSQL allocates memory for its needs? |
| Date: | 2010-02-11 03:46:52 |
| Message-ID: | dcc563d11002101946o36d022e6me20c65cfff81b894@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Feb 10, 2010 at 9:43 AM, Justin Graf <justin(at)magwerks(dot)com> wrote:
> Keep in mind each connection/client that connecting to the server
> creates a new process on the server. Each one the settings you list
> above is the max amount of memory each one of those sessions is allowed
> to consume.
It's even worse for work_mem (formerly sort_mem) in that each
individual hash agg or sort can grab that much memory. A complex
query with 4 sorts and 2 hash aggregates could chew through 6 x
work_mem if it needed it. Which is why work_mem can be such a
horrific foot gun.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-02-11 03:52:49 | Re: Re: 512, 600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk? |
| Previous Message | Andres Freund | 2010-02-11 02:27:30 | Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |