On Fri, Feb 18, 2011 at 2:27 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
On 17.02.2011 14:30, Gurjeet Singh wrote:
On Wed, Feb 16, 2011 at 6:37 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Fetch the values you need and stuff 'em in the struct. Don't expect
relcache to do it for you. The only reason relcache is involved in the
current workflow is that we try to cache the information across queries
in order to save on planner startup time ... but I don't think that that
concern is nearly as pressing for something like Index Advisor. You'll
have enough to do tracking changes in IndexOptInfo, you don't need to
have to deal with refactorings inside relcache as well.
I also wish to make Index Advisor faster by not having to lookup this info
every time a new query comes in and that's why I was trying to use the guts
of IndexSupportInitialize() where it does the caching.
The question is, can the Index Advisor easilt access all the information it needs to build the IndexOptInfo? If not, what's missing?
There's a command line tool in the Index Adviser contrib that takes a file full of SQL and run them against the Index Adviser. People would want that tool to be as fast as it can be.
Another use case of the Index Advisor is to be switched on for a few hours while the application runs, and gather the recommendations for the whole run. We'll need good performance that case too.
I'll try to figure out what all info we need for IndexOptInfo, it'll take some time though.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.comsingh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device