Re: Postgres query completion status?
От | Richard Neill |
---|---|
Тема | Re: Postgres query completion status? |
Дата | |
Msg-id | 4B095459.9040100@cam.ac.uk обсуждение исходный текст |
Ответ на | Postgres query completion status? (Richard Neill <rn214@cam.ac.uk>) |
Список | 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@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-performance > >
В списке pgsql-performance по дате отправления: