Re: Index not used on single select, but used in join.
От | Francisco Reyes |
---|---|
Тема | Re: Index not used on single select, but used in join. |
Дата | |
Msg-id | 20011107183835.Y27009-100000@zoraida.natserv.net обсуждение исходный текст |
Ответ на | Re: Index not used on single select, but used in join. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Index not used on single select, but used in join.
|
Список | pgsql-novice |
On Wed, 7 Nov 2001, Tom Lane wrote: > What does EXPLAIN actually show for you? If you try to force an > indexscan by doing "SET enable_seqscan TO off", does the EXPLAIN > result change? Have you VACUUM ANALYZEd the table recently? After I tested with setting enable_seqscan to off I did a VACUUM ANALYZE. Turned the variable to on and did another explain. It is back to trying to do a sequential scan. drf=# SET enable_seqscan TO on; SET VARIABLE drf=# explain select horse from hraces where lower(horse) = 'little irish nut'; NOTICE: QUERY PLAN: Seq Scan on hraces (cost=0.00..208976.96 rows=75793 width=12) EXPLAIN It is a little troublesome that the optimizer is choosing the sequential scan. This query with lower(horse) is extremely common in our environment. We are a Foxpro and Oracle shop and I am jut starting to do tests with PostgreSQL to see its capability to handle at least part of our operation in the future.
В списке pgsql-novice по дате отправления: