Re: two queries and dual cpu (perplexed)

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)

OUCH, OUCH, OUCH.

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
increase.

Regards

Russell Smith.