> You mentioned earlier that to get around the CS bug, avoid the query
> structures which trigger it. Dumb question: How do you isolate this?

In real terms, it's generally triggered by a query joining against a very 
large table requiring a seq scan.

You can probably find the "bad queries" just by using PQA, and looking for 
select, delete and update queries which last over 60 seconds. 

> Is there a way in a Postgresql query to only look at 1 processor only in
> a dual-CPU setup?

That would be an OS question.    I personally can't see how.

> Any likelyhood this CS storm will be understood in the next couple months?

It's well understood.   See the archives of this list.   The problem is that 
implementing the solution is very, very hard -- 100+ hours from a top-notch 
programmer.  I'm still hoping to find a corporate sponsor for the issue ...

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to