Re: Performance degradation 8.4 -> 9.1 - Mailing list pgsql-general

From Joseph Shraibman
Subject Re: Performance degradation 8.4 -> 9.1
Date
Msg-id 4EC57425.5020803@selectacast.net
Whole thread Raw
In response to Re: Performance degradation 8.4 -> 9.1  (Michael Glaesemann <grzm@seespotcode.net>)
List pgsql-general
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 EXPLAIN for 8.4, it's kind of hard
tosay. 
>
> Does this formulation of the query give you a different plan?
>
> SELECT status,
>        e4.type IS NOT NULL,
>        e1.type IS NOT NULL
>   FROM maillog ml
>   LEFT JOIN eventlog e4 ON (e4.uid, e4.jobid) = (ml.uid, ml.jobid)
>                         AND e4.type = 4
>   LEFT JOIN eventlog e1 ON (e1.uid, e1.jobid) = (ml.uid, ml.jobid)
>                     AND e1.type = 1
>   WHERE jobid = 1132730;
>
It does, but still not the right plan.  I want pg to use the plan I
posted, minus the seqscan.  It estimates that subplan 1 is faster than
subplan 2 and they both would give the same results, so why is it
running subplan 2?

BTW setting enable_seqscan = false on the original doens't solve my
problem, I get this instead which is still slow.


 => explain verbose
owl-> SELECT status , --dsn,servername,software,serverip,ip,pod,format,
owl-> EXISTS(SELECT 1 FROM eventlog e WHERE e.uid = ml.uid AND e.jobid =
ml.jobid AND type = 4),
owl-> EXISTS(SELECT 1 FROM eventlog e WHERE e.uid = ml.uid AND e.jobid =
ml.jobid AND type = 1) FROM maillog ml WHERE jobid IN(1132730);
                                                      QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
 Index Scan using maillog_jobid_status_key on public.maillog ml
(cost=0.00..120407480.20 rows=338951 width=10)
   Output: ml.status, (alternatives: SubPlan 1 or hashed SubPlan 2),
(SubPlan 3)
   Index Cond: (ml.jobid = 1132730)
   SubPlan 1
     ->  Index Scan using eventlog_uid_and_jobid_and_type_key on
public.eventlog e  (cost=0.00..176.71 rows=1 width=0)
           Index Cond: ((e.uid = ml.uid) AND (e.jobid = ml.jobid) AND
(e.type = 4))
   SubPlan 2
     ->  Bitmap Heap Scan on public.eventlog e
(cost=21708484.94..43874627.61 rows=17541300 width=8)
           Output: e.uid, e.jobid
           Recheck Cond: (e.type = 4)
           ->  Bitmap Index Scan on eventlog_jobid_type_type
(cost=0.00..21704099.62 rows=17541300 width=0)
                 Index Cond: (e.type = 4)
   SubPlan 3
     ->  Index Scan using eventlog_uid_and_jobid_and_type_key on
public.eventlog e  (cost=0.00..176.71 rows=1 width=0)
           Index Cond: ((e.uid = ml.uid) AND (e.jobid = ml.jobid) AND
(e.type = 1))
(15 rows)




pgsql-general by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: Performance degradation 8.4 -> 9.1
Next
From: "J.V."
Date:
Subject: Re: monitoring sql queries