Re: Nested loops overpriced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2007/5/9, Gregory Stark <stark@xxxxxxxxxxxxxxxx>:

"Daniel Cristian Cruz" <danielcristian@xxxxxxxxx> writes:

>   ->  Nested Loop  (cost=0.00..13187.94 rows=93 width=4) (actual time=2.622..125.739 rows=50 loops=1)
>         ->  Seq Scan on u  (cost=0.00..2838.80 rows=10289 width=4) (actual time=0.012..9.863 rows=10291 loops=1)
>         ->  Index Scan using m_pkey on m  (cost=0.00..0.80 rows=1 width=7) (actual time=0.009..0.009 rows=0 loops=10291)

That's not discounting the nested loop for cache effect at all!

What is your effective_cache_size for this?

effective_cache_size is 5400MB.

I forgot to mention a modifications on cost:
cpu_tuple_cost = 0.2
Which forced a usage of indexes.

I set it to 0.01 and the plan has a index scan on m before the hash on
u, being 15% slower:

        Hash Cond: ((u.i)::text = (m.i)::text)
        ->  Seq Scan on u  (cost=0.00..2838.80 rows=10289 width=4)
(actual time=0.007..6.138 rows=10292 loops=1)
        ->  Hash  (cost=87.30..87.30 rows=30 width=7) (actual
time=0.185..0.185 rows=50 loops=1)
              ->  Index Scan using m_pkey on m  (cost=0.00..87.30
rows=30 width=7) (actual time=0.021..0.144 rows=50 loops=1)
                    Index Cond: (t = 1615)
                    Filter: ((a)::text = 'Y'::text)

I'm still confused since I didn't understood what "That's not
discounting the nested loop for cache effect at all!" could mean...

Thanks for the help.
--
Daniel Cristian Cruz


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux