> On 10/10/06, Mark Woodward <[EMAIL PROTECTED]> wrote:
>> I think the idea of "virtual indexes" is pretty interesting, but
>> ultimately a lesser solution to a more fundimental issue, and that would
>> be "hands on" control over the planner. Estimating the effect of an
>> index
>> on a query "prior" to creating the index is a great idea, how that is
>> done
>> is something different than building concensus that it should be done.
>>
>> Another thing that this brings up is "hints" to a query. Over the years,
>> I
>> have run into situation where the planner wasn't great. It would be
>> nice
>> to try forcing different strategies on the planner and see if
>> performance
>> caan be improved.
>>
>
> you can do this by setting enable_"access_method" type parameters.
Here's your hammer, all your problems are now nails.
The enable_xxx setting are OK for simple queries gone wrong, but if you
have a more complex query, any one of those settins may help or hinder
different parts of a query, then you would be left with choosing which of
them helps more than hurts the over-all query.
being able to alter the query plan would help in areas where there are
data patterns in a database that the ANALYZE command can't pick up because
it is not designed too.
Imagine you have a street map database ordered by zip, street, number. The
primary order is zipcode, the secondary order is street. There is a
relationship of number to street, and zip to street. The analyzer, at
least the last time I checked, does not recognize these relationships. So,
a search by street and number would probably use a sequential scan rather
than the street index.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
