Re: [SQL] indexes

Remigiusz Sokolowski <rems@gdansk.sprint.pl> writes:
> NOTICE:  QUERY PLAN:
> Unique  (cost=77.02 size=0 width=0)
>   ->  Sort  (cost=77.02 size=0 width=0)
>         ->  Nested Loop  (cost=77.02 size=1 width=28)
>               ->  Nested Loop  (cost=74.97 size=1 width=12)
>                     ->  Seq Scan on b1  (cost=72.97 size=1 width=8)
>                     ->  Index Scan on e2  (cost=2.00 size=1 width=4)
>               ->  Index Scan on e1  (cost=2.05 size=1304 width=16)
> 

I think the real problem here is that the optimizer thinks your tables
are small (notice the size=1 estimates in the inner loop).  Have you
done a VACUUM lately?  You need that to update the statistics that the
optimizer uses.

Unless you are dealing with very small tables, you don't want to see
nested-loop joins (that means scanning the lower table once for each
tuple in the upper table!).  You want to see merge joins or hash joins.

Vadim's suggestion of a better-adapted index was a good one, but I
wonder whether the speedup you saw wasn't just a side effect from
CREATE INDEX having updated the optimizer's stats, so that it stopped
using nested loops...
        regards, tom lane