From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
Cc: | Alan McKay <alan(dot)mckay(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: query memory consumption |
Date: | 2009-09-26 03:06:42 |
Message-ID: | f67928030909252006s338c8851sdf2b3df704534367@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2009/9/22 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
> On Tue, Sep 22, 2009 at 1:46 PM, Alan McKay <alan(dot)mckay(at)gmail(dot)com> wrote:
>>> Best practice to avoid that, is to bump the work_mem temporarily
>>> before the query, and than lower it again, lowers the chance of memory
>>> exhaustion.
>>
>> Interesting - I can do that dynamically?
>
> you can do set work_mem=128M; select 1; set work_mem=64M;
>
> etc, in one query.
But if all backends are running this one query at the same time, it
won't help because they will all bump up their limits at the same
time. If they are all running different queries, and just one of them
really gets a big benefit from the extra memory, but the rest just use
it because they think they have it even though it is only a small
benefit, then bumping up just for the query that gets a big
improvement could work.
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Xia Qingran | 2009-09-26 13:05:28 | Bad performance of SELECT ... where id IN (...) |
Previous Message | Jeff Janes | 2009-09-26 02:53:56 | Re: PG 8.3 and large shared buffer settings |