Re: select slows from 3 seconds to 30 seconds
От | Gary Stainburn |
---|---|
Тема | Re: select slows from 3 seconds to 30 seconds |
Дата | |
Msg-id | 200705081108.18881.gary.stainburn@ringways.co.uk обсуждение исходный текст |
Ответ на | Re: select slows from 3 seconds to 30 seconds (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: