Thread: select slows from 3 seconds to 30 seconds

select slows from 3 seconds to 30 seconds

From
Gary Stainburn
Date:
Hi folks.

I have the query below which when run takes approx 3 seconds.  However when I 
add the condition 'and w_ws_id = 10' onto the end changes to 30+ seconds. 

Can anyone see why? I've included the explain for the long select.

select w_vin as key, w_vin, v_o_number as vista, v_status,       s_stock_no, s_customer_order,
coalesce(d.r_registration,p.r_registration, w_reg_no) as 
 
reg_no,w_arrival,       w_updated::date,CURRENT_DATE-w_created::date as age, w_model,       w_radio_code, w_key_no,
w_inspected,w_damage,       w_walon_repair,w_collect_date, w_despatch_date, w_sheet,       w_plates, w_accessories,
coalesce(p.d_des, d.d_des) as d_des,      coalesce(p.de_des, d.de_des) as de_des,      p.r_id as pdi,       d.r_id as
delivery,     o.o_id, o.state from walon  left outer join request_details p on p.t_id = 'P' and
substring(p.r_chassisfrom '(.{11}$)') = w_vin left outer join request_details d on d.t_id = 'D' and
substring(d.r_chassisfrom '(.{11}$)') = w_vin left outer join order_details o on        substring(o.o_vin from
'(.{11}$)')= w_vin left outer join stock s on substring(s.s_vin from '(.{11}$)') = w_vin left outer join vista v on
v.v_vin= w_vin where  w_hide = 0.
 


-- 
Gary Stainburn
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000

Re: select slows from 3 seconds to 30 seconds

From
Tom Lane
Date:
Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> I have the query below which when run takes approx 3 seconds.  However when I
> add the condition 'and w_ws_id = 10' onto the end changes to 30+ seconds.
> Can anyone see why? I've included the explain for the long select.

You really ought to provide EXPLAIN ANALYZE output for both versions if
you want intelligent commentary --- otherwise we're just guessing.

But I would guess the problem is that the planner is way off about the
number of rows satisfying the joint condition --- it thinks two:

>                            ->  Index Scan using walon_hide_index on walon  (cost=0.00..85.04 rows=2 width=140)
>                                  Index Cond: (w_hide = 0)
>                                  Filter: (w_ws_id = 10)

This plan is good if there really are only a couple rows, but degrades
quickly if there are many...
        regards, tom lane


Re: select slows from 3 seconds to 30 seconds

From
Gary Stainburn
Date:
On Saturday 05 May 2007 01:57, Tom Lane wrote:
> Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> > I have the query below which when run takes approx 3 seconds.  However
> > when I add the condition 'and w_ws_id = 10' onto the end changes to 30+
> > seconds. Can anyone see why? I've included the explain for the long
> > select.
>
> You really ought to provide EXPLAIN ANALYZE output for both versions if
> you want intelligent commentary --- otherwise we're just guessing.
>
> But I would guess the problem is that the planner is way off about the
>
> number of rows satisfying the joint condition --- it thinks two:
> >                            ->  Index Scan using walon_hide_index on walon
> >  (cost=0.00..85.04 rows=2 width=140) Index Cond: (w_hide = 0)
> >                                  Filter: (w_ws_id = 10)
>
> This plan is good if there really are only a couple rows, but degrades
> quickly if there are many...
>
>             regards, tom lane

Thanks Tom

I'll bear that in mind in future.

The problem was fixed by running a 'vacuum analyse' so it looks like the 
planner was getting confused.

Gary


-- 
Gary Stainburn
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000