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
