On Thu, 21 Apr 2005 10:44 pm, Shoaib Burq (VPAC) wrote:
>   ->  Nested Loop  (cost=2.19..1069345.29 rows=16 width=58) (actual 
> time=135.390..366902.373 rows=13276368 loops=1)
>                      ->  Nested Loop  (cost=2.19..1067304.07 rows=44 
> width=68) (actual time=107.627..186390.137 rows=13276368 loops=1)
>                            ->  Nested Loop  (cost=2.19..1067038.94 rows=44 
> width=52) (actual time=87.255..49743.796 rows=13276368 loops=1)


Most if not all of the time is going on nested loop joins.  The tuple estimates 
are off by a factore of 10^6 which is means it's chosing the wrong
join type.

you could set enable_seqscan to OFF;  to test what he performance is like with 
a different plan, and then set it back on.

However you really need to get the row count estimates up to something 
comparable.  within a factor of 10 at least.
A number of the other rows estimates seem to be off by a reasonable amount too. 
 You may want to bump up the statistics on the relevant
columns.  I can't find what they are from looking at that, I probably should be 
able too, but it's late.

If you get the stats up to something near the real values, then the planner 
will choose a different plan, which should give a huge performance


Russell Smith.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to