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. Take a look at the Linux kernel mailing list,
and you'll probably find good articles at Linux Weekly News (lwn.net.)
On 2004.03.06 23:32 Gavin M. Roy wrote:
> 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 an adaptec 7899 Ultra 160 SCSI card w/
> accompanying fast drives...
>
> Again, I'll send the explain, etc if you think it would help answer
> my question, but from my perspective, the amount of time the query
> takes to execute isnt my issue, but the fact that nothing else can
> seemingly execute while its running.
>
> Gavin
>
> Tom Lane wrote:
>
>> "Gavin M. Roy" <gmr@ehpg.net> 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 schemas for all the tables
>> involved.)
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
