Re: [SQL] select slows from 3 seconds to 30 seconds

2007-05-08 Thread Gary Stainburn
On Saturday 05 May 2007 01:57, Tom Lane wrote:
 Gary Stainburn [EMAIL PROTECTED] 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 

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


[SQL] select slows from 3 seconds to 30 seconds

2007-05-04 Thread Gary Stainburn
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_chassis from '(.{11}$)') = w_vin
  left outer join request_details d on d.t_id = 'D' and 
substring(d.r_chassis from '(.{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 

   QUERY PLAN   


 Nested Loop Left Join  (cost=14430.85..16251.57 rows=2 width=427)
   -  Nested Loop Left Join  (cost=14430.85..16239.49 rows=2 width=405)
 Join Filter: (substring((inner.s_vin)::text, '(.{11}$)'::text) = 
(outer.w_vin)::text)
 -  Nested Loop Left Join  (cost=13060.02..14496.72 rows=2 width=394)
   Join Filter: (substring((inner.o_vin)::text, 
'(.{11}$)'::text) = (outer.w_vin)::text)
   -  Nested Loop Left Join  (cost=6635.38..7785.17 rows=2 
width=352)
 Join Filter: (substring((inner.r_chassis)::text, 
'(.{11}$)'::text) = (outer.w_vin)::text)
 -  Nested Loop Left Join  (cost=3617.97..4441.81 rows=2 
width=246)
   Join Filter: (substring((inner.r_chassis)::text, 
'(.{11}$)'::text) = (outer.w_vin)::text)
   -  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)
   -  Materialize  (cost=3617.97..3861.73 rows=8376 
width=127)
 -  Subquery Scan p  (cost=2372.95..3449.59 
rows=8376 width=127)
   -  Merge Join  (cost=2372.95..3365.83 
rows=8376 width=196)
 Merge Cond: (outer.r_id = 
inner.r_id)
 -  Merge Left Join  
(cost=208.05..954.29 rows=14895 width=20)
   Merge Cond: (outer.r_id = 
inner.co_r_id)
   -  Merge Left Join  
(cost=105.13..810.93 rows=14895 width=12)
 Merge Cond: 
(outer.r_id = inner.co_r_id)
 -  Index Scan using 
requests_pkey on requests r  (cost=0.00..653.03 rows=14895 width=4)
 -  Sort  
(cost=105.13..107.72 rows=1036 width=12)
   Sort Key: 
co.co_r_id
   -  Subquery 
Scan co  (cost=29.93..53.24 rows=1036 width=12)
 -  
HashAggregate  (cost=29.93..42.88 rows=1036 width=4)
   -  
Seq Scan on comments  (cost=0.00..24.62 rows=1062 width=4)
   -  Sort  
(cost=102.93..103.46 rows=213 width=12)
 Sort Key: cor.co_r_id
 -  Subquery Scan cor  
(cost=89.90..94.69 rows=213 width=12)
   -  
HashAggregate  (cost=89.90..92.56 rows=213 width=4)
 -  Hash 

Re: [SQL] select slows from 3 seconds to 30 seconds

2007-05-04 Thread Tom Lane
Gary Stainburn [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org