From: | "John Vincent" <pgsql-performance(at)lusis(dot)org> |
---|---|
To: | "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com> |
Cc: | "PGSQL Performance" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Performance of pg_dump on PGSQL 8.0 |
Date: | 2006-06-14 20:55:00 |
Message-ID: | c841561b0606141355g5b00b27ey257bbfc661dccfb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 6/14/06, Scott Marlowe <smarlowe(at)g2switchworks(dot)com> wrote:
>
>
> Description of "Queries gone wild" redacted. hehe.
>
> Yeah, I've seen those kinds of queries before too. you might be able to
> limit your exposure by using alter user:
>
> alter user userwhoneedslotsofworkmem set work_mem=1000000;
Is this applicable on 8.0? We were actually LOOKING for a governor of some
sort for these queries. And something that is not explicitly stated, is
that allocated up front or is that just a ceiling?
and then only that user will have that big of a default. You could even
> make it so that only queries that need that much log in as that user,
> and all other queries log in as other folks. Just a thought. I just
> get REAL nervous seeing a production machine with a work_mem set that
> high.
Which is actually how it's configured. We have a dedicated user connecting
from Actuate. The reports developers use thier own logins when developing
new reports. Only when they get published do they convert to the Actuate
user.
--
John E. Vincent
lusis(dot)org(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-06-14 21:03:35 | Re: Performance of pg_dump on PGSQL 8.0 |
Previous Message | Scott Marlowe | 2006-06-14 20:11:37 | Re: Performance of pg_dump on PGSQL 8.0 |