Search Postgresql Archives

Re: Performance degradation 8.4 -> 9.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 to say.
> 
> 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)




-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux