Steve, > 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]
