From: | Richard Neill <rn214(at)cam(dot)ac(dot)uk> |
---|---|
To: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres query completion status? |
Date: | 2009-11-22 15:10:17 |
Message-ID: | 4B095459.9040100@cam.ac.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Justin Pitts wrote:
> I don't know if I would call it "terribly" ugly. Its not especially
> pretty, but it affords the needed degree of twiddling to get the job
> done. Relying on the clients is fine - if you can. I suspect the vast
> majority of DBAs would find that notion unthinkable. The usual result of
> a memory overrun is a server crash.
>
It's probably OK in this context: the multiple clients are all instances
of the same perl script, running particular, pre-defined queries. So we
can trust them not to ask a really memory-intensive query.
Besides which, if you can't trust the clients to ask sensible queries,
why can you trust them to set their own work_mem values?
Richard
> On Nov 20, 2009, at 4:39 PM, Richard Neill wrote:
>
>> Justin Pitts wrote:
>>> Set work_mem in postgresql.conf down to what the 200 clients need,
>>> which sounds to me like the default setting.
>>> In the session which needs more work_mem, execute:
>>> SET SESSION work_mem TO '256MB'
>>
>> Isn't that terribly ugly? It seems to me less hackish to rely on the
>> many clients not to abuse work_mem (as we know exactly what query they
>> will run, we can be sure it won't happen).
>>
>> It's a shame that the work_mem parameter is a per-client one, rather
>> than a single big pool.
>>
>> Richard
>>
>> --
>> Sent via pgsql-performance mailing list
>> (pgsql-performance(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Neill | 2009-11-22 15:14:22 | Re: Postgres query completion status? |
Previous Message | Richard Neill | 2009-11-22 15:10:11 | Re: Postgres query completion status? |