From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, Alan McKay <alan(dot)mckay(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: query memory consumption |
Date: | 2009-09-27 18:40:04 |
Message-ID: | 603c8f070909271140n38f84884tfe1070202110b23@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2009/9/25 Jeff Janes <jeff(dot)janes(at)gmail(dot)com>:
> 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.
This is, I think, a possible area for future optimizer work, but the
right design is far from clear.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-09-27 18:45:26 | Re: Slow query after upgrade to 8.4 |
Previous Message | Robert Haas | 2009-09-27 18:38:06 | Re: Regarding Sequential Scans count increase each time we press refresh . |