Nabil Sayegh <nsmail@sayegh.de> writes:
> What makes me wonder is:
> => \d best_ez_hotel_id_key
> Index "best_ez_hotel_id_key"
> Attribute | Type
> -----------+--------------
> hotel_id | varchar(200)
> datum | date
> unique btree
> best_ez_hotel_id_key is the (unique) key I use in best_ez. But it seems
> like it ALWAYS ignores this (Seq Scan on best_ez).
That index is useless for this query, since you have no restriction
clause on hotel_id, which is the major sort key for the index. If the
index were on (datum, hotel_id) then it might be profitable to use the
WHERE clauses about datum with the index.
The index could be used for performing the join, if this table were
the inner table, but the planner is deciding to put this table on the
outside and use the other table's index for joining instead. That's
probably the correct choice given the other restriction clauses.
regards, tom lane