More info:
I upgraded the database from 8.4 to 9.1 using pg_upgrade, so I have no
way of running explain using 8.4.
I don't want to do an EXPLAIN ANALYZE because it would bog down the
server for too long. I know what it is doing, it's doing a seqscan.
This is a table with ~ 5.5 million rows
On 18 Listopad 2011, 11:39, Greg Smith wrote:
> On 11/17/2011 02:24 PM, Joseph Shraibman wrote:
>> This query is taking much longer on 9.1 than it did on 8.4. Why is it
>> using a seq scan?
>>
>
> To answer that question in all cases, it's necessary to know a) the
> query, b) the PostgreSQL versio
On 11/17/2011 02:24 PM, Joseph Shraibman wrote:
This query is taking much longer on 9.1 than it did on 8.4. Why is it
using a seq scan?
To answer that question in all cases, it's necessary to know a) the
query, b) the PostgreSQL version, c) the table definitions including
what indexes ex
On 11/17/2011 03:30 PM, Michael Glaesemann wrote:
>
> On Nov 17, 2011, at 14:24, Joseph Shraibman wrote:
>
>> This query is taking much longer on 9.1 than it did on 8.4. Why is it
>> using a seq scan?
>
> Without seeing the table definition (including indexes) as well as the output
> of EXPLAI
On Nov 17, 2011, at 14:24, Joseph Shraibman wrote:
> This query is taking much longer on 9.1 than it did on 8.4. Why is it
> using a seq scan?
Without seeing the table definition (including indexes) as well as the output
of EXPLAIN for 8.4, it's kind of hard to say.
Does this formulation of t
This query is taking much longer on 9.1 than it did on 8.4. Why is it
using a seq scan?
=> explain verbose SELECT status,EXISTS(SELECT 1 FROM eventlog e WHERE
e.uid = ml.uid AND e.jobid = ml.jobid AND type = 4),EXISTS(SELECT 1 FROM
eventlog e WHERE e.uid = ml.uid AND e.jobid = ml.jobid AND type =
