From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | david(at)lang(dot)hm, "Carlos Moreno" <moreno_pg(at)mochima(dot)com>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz> |
Cc: | "Daniel Griscom" <griscom(at)suitable(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Throttling PostgreSQL's CPU usage |
Date: | 2007-05-09 04:09:59 |
Message-ID: | C26697A8.2F99F%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
You can use the workload management feature that we've contributed to
Bizgres. That allows you to control the level of statement concurrency by
establishing queues and associating them with roles.
That would provide the control you are seeking.
- Luke
On 5/8/07 4:24 PM, "david(at)lang(dot)hm" <david(at)lang(dot)hm> wrote:
> On Tue, 8 May 2007, Carlos Moreno wrote:
>
>> Daniel Griscom wrote:
>>>
>>> Several people have mentioned having multiple processors; my current
>>> machine is a uni-processor machine, but I believe we could spec the actual
>>> runtime machine to have multiple processors/cores.
>>
>> My estimate is that yes, you should definitely consider that.
>>
>>> I'm only running one query at a time; would that query be guaranteed to
>>> confine itself to a single processor/core?
>>
>> From what Joshua mentions, looks like you do have that guarantee.
>
> isn't there a way to limit how many processes postgres will create?
>
> if this is limited to 1, what happens when a vaccum run hits (or
> autovaccum)
>
> David Lang
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-05-09 04:14:42 | Re: |
Previous Message | Greg Smith | 2007-05-09 03:51:51 | Re: Best OS for Postgres 8.2 |