Payal Singh-2 wrote
>>Postgres chooses the best, most efficient way to optimize
>> the query, and so if your index actually has the potential to improve the
>> select query at hand, postgres will choose it. If there is a better way
>> to
>> execute your query than using your index, postgres will not use it.
To be fair PostgreSQL is not infallible so if you have a situation where you
believe PostgreSQL should be using an index where it is not then such a
situation should be documented in detail and sent to the list. You can use
various "enable_" GUC to disable sequential scanning and index scanning so
that supposedly sub-optimal plans are more likely to be chosen (i.e., you
cannot absolutely disable sequential scans since in some cases brute-force
is the only valid method to execute a query). Costing parameters can also
be altered to better reflect your actual system.
In short the project's policy is to fix underlying problems (via code or
configuration) rather than implement planner hints that simply allow people
to more often shoot themselves in the foot rather than provide a permanent
solution.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Using-index-name-in-select-Query-tp5775138p5775148.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.
