From: | Samuel Gendler <sgendler(at)ideasculptor(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: in-memory sorting |
Date: | 2010-08-19 06:38:50 |
Message-ID: | AANLkTinhNT_QujPGhFoqUX9ts2hW-4whvMOWNBXhwU0=@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Yeah, although with 48GB of available memory and not that much concurrency,
I'm not sure it matters that much. But point taken, I'll see about modifying
the app such that work_mem gets set on a per-query basis.
On Wed, Aug 18, 2010 at 11:24 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:
> On Wed, Aug 18, 2010 at 11:45 PM, Samuel Gendler
> <sgendler(at)ideasculptor(dot)com> wrote:
> > Answered my own question. Cranking work_mem up to 350MB revealed that
> > the in-memory sort requires more memory than the disk sort.
>
> Note that unless you run VERY few client connections, it's usually
> better to leave work_mem somewhere in the 1 to 32Meg range and have
> the connection or user or database that needs 350Meg be set there.
>
> I.e.
>
> <connect>
> set work_mem='512MB';
> <execute query
>
> OR
>
> alter user memoryhog set work_mem='512MB';
>
> OR
>
> alter database memhogdb set work_mem='512MB';
>
From | Date | Subject | |
---|---|---|---|
Next Message | Samuel Gendler | 2010-08-19 06:50:29 | Re: yet another q |
Previous Message | Scott Marlowe | 2010-08-19 06:24:55 | Re: in-memory sorting |