Thanks, I'll take a look, we've rewritten the queries and indexes to
avoid the issue, but I'd like to get an ultimate solution to the issue,
and the concept that it's a linux kernel scheduling thing is probably
dead on.
Gavin
Karl O. Pinc wrote:
This reminds me of the scheduler optimizations
This reminds me of the scheduler optimizations that have been flying
around the Linux kernel deveopment over the last year or so. There are
cases apparently where this kind of behavior can come up. IIRC it's
fixed in later kernels but don't take my word for it, I'm just writing
to give a heads-up
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> ... the issue seems to be more revolving around the
> backend getting so much cpu priority it's not allowing other backends to
> process, or something along those lines.
I can't think of any difference between 7.3 and 7.4 that would create
a problem o
I'll post it if you want, but the issue isn't with the optimizer, index
usage, or seq scan, the issue seems to be more revolving around the
backend getting so much cpu priority it's not allowing other backends to
process, or something along those lines. For the hardware question
asked, it's a
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> It's not WAITING, the larger queries are eating cpu (99%) and the rest
> are running so slow it would seem they're waitng for processing time.
Could we see EXPLAIN ANALYZE output for the large query? (Also the
usual supporting evidence, ie table sch
"Gavin M. Roy" said:
> I upgraded my main production db from 7.3.4 last night to 7.4.1. I'm
> running into an issue where a big query that may take 30-40 seconds to
> reply is holding up all other backends from performing their queries.
> Once the big query is finished, all the tiny ones fly
It is using indexs, and not seqscan, and there was an analyze after
reload... I'll play with GEQO, thanks.
Gavin
Mike Mascari wrote:
Gavin M. Roy wrote:
I upgraded my main production db from 7.3.4 last night to 7.4.1. I'm
running into an issue where a big query that may take 30-40 seconds
t
It's not WAITING, the larger queries are eating cpu (99%) and the rest
are running so slow it would seem they're waitng for processing time.
My sort mem is fairly high, but this is a dedicated box, and there is no
swapping going on afaik,
Gavin
Andrew Sullivan wrote:
On Sat, Mar 06, 2004 at
Gavin M. Roy wrote:
I upgraded my main production db from 7.3.4 last night to 7.4.1. I'm
running into an issue where a big query that may take 30-40 seconds to
reply is holding up all other backends from performing their queries.
Once the big query is finished, all the tiny ones fly through.
On Sat, Mar 06, 2004 at 01:12:57PM -0800, Gavin M. Roy wrote:
> I upgraded my main production db from 7.3.4 last night to 7.4.1. I'm
> running into an issue where a big query that may take 30-40 seconds to
> reply is holding up all other backends from performing their queries.
By "holding up"
10 matches
Mail list logo
