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 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
