> Still doing the sequential scan on the table, but at least it's
> avoiding the expensive disk merge sort. It still seems as if I ought
> to be able to coax it into using an index for this type of query,
> though- especially since it's using one on the other table. Is there
> perhaps some way to reformulate the index in such a way as to make it
> more useful to the planner?
You're asking postgres to examine EVERY visible row (hence the sequential scan
makes good sense), and tell you what field values there are.
You may be able to make use of an index by rearranging your query to generate a
series between your min & max values, testing whether each value is in your
table.
You've got 4252 distinct values, but what is the range of max - min? Say it's
5000 values, you'd do 5000 lookups via an index, unless postgres thought that
the number of index based lookups where going to be more expensive than reading
the entire table.
Regards,
Stephen Denne.
Disclaimer:
At the Datamail Group we value team commitment, respect, achievement, customer
focus, and courage. This email with any attachments is confidential and may be
subject to legal privilege. If it is not intended for you please advise by
reply immediately, destroy it and do not copy, disclose or use it in any way.
__________________________________________________________________
This email has been scanned by the DMZGlobal Business Quality
Electronic Messaging Suite.
Please see http://www.dmzglobal.com/dmzmessaging.htm for details.
__________________________________________________________________
--
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
