| From: | Francisco Reyes <lists(at)natserv(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Francisco Reyes <lists(at)natserv(dot)com>, Pgsql Novice <pgsql-novice(at)postgresql(dot)org> |
| Subject: | Re: Index not used on single select, but used in join. |
| Date: | 2001-11-07 23:48:12 |
| Message-ID: | 20011107183835.Y27009-100000@zoraida.natserv.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-11-08 00:07:34 | Re: Index not used on single select, but used in join. |
| Previous Message | Francisco Reyes | 2001-11-07 23:36:21 | Re: Index not used on single select, but used in join. |