On Tue, 2007-04-10 at 12:18 -0700, Gurjeet Singh wrote: > Also, although the whole plan-tree is available in > get_relation_info(), but it wouldn't be the right place to scan other > tables, for eg., for generating JOIN-INDEXes or materializing some > intermediate joins. (sometime in the future we may support them!).
I like Tom's suggestion. We never thought actually creating the indexes was a very good thing and I'd be happy to bury that idea for good. Speed is definitely a consideration if we are to re-plan thousands of SQL statements for a real workload. > If we don't run the planner twice, then the developer will have to > run it manually twice, and compare the costs manually (with and > without v-indexes); virtually impossible for lage applications and > introduction of another human-error possibility. AFAICS Tom hasn't referred to running twice or not, so I'm not very sure what you're referring to, sorry. If you could answer Tom's suggestions one by one directly underneath them it would be easier to discuss things. ISTM that you've done a great job, the trick is now to reach agreement and finish this. If there is something still to discuss, it needs to be very clearly tied back to Tom's comments so everyone can follow it, then agree it. If there is a problem in Tom's suggestions that directly effects the operation of the tool then we need to identify what that is. But if those hooks would give us all we need, then lets agree it and fix up the adviser plug-in later. We really, really, really need this. Lots. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
