Re: LIKE optimization
От | Tom Lane |
---|---|
Тема | Re: LIKE optimization |
Дата | |
Msg-id | 17202.979748180@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: LIKE optimization (Nabil Sayegh <nsmail@sayegh.de>) |
Список | pgsql-novice |
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
В списке pgsql-novice по дате отправления: