| From: | "Mark Woodward" <pgsql(at)mohawksoft(dot)com> | 
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Index Tuning Features | 
| Date: | 2006-10-11 00:17:20 | 
| Message-ID: | 22014.24.91.171.78.1160525840.squirrel@mail.mohawksoft.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> - RECOMMEND command
>
>> Similar in usage to an EXPLAIN, the RECOMMEND command would return a
>> list of indexes that need to be added to get the cheapest plan for a
>> particular query (no explain plan result though).
>
> Both of these seem to assume that EXPLAIN results, without EXPLAIN
> ANALYZE results to back them up, are sufficient for tuning.  I find
> this idea a bit dubious, particularly for cases of "marginal" indexes.
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-10-11 01:17:28 | Change view ownership | 
| Previous Message | Tom Lane | 2006-10-10 23:15:09 | Re: Index Tuning Features |