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
>> to reply is holding up all other backends from performing their
>> queries. Once the big query is finished, all the tiny ones fly
>> through. This is seemingly ne behavior on the box, as with previous
>> versions things would slow down, but not wait for the cpu/resource
>> hog queries to finish. The box is Slackware 8.1, on a fairly decent
>> box with plenty of ram, cpu, and disk speed. I've considered
>> renicing the processes, I was wondering if anyone had a different
>> suggestion.
>
>
> Hi Gavin.
>
> Assuming a VACUUM ANALYZE after reload, one possibility is that the
> query in question contains >= 11 joins. I forgot to adjust the GEQO
> settings during an upgrade and experienced the associated sluggishness
> in planning time.
>
> Mike Mascari
>
>
