| 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: | Whole Thread | Raw Message | 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 |