Re: Overriding the optimizer

On Fri, 16 Dec 2005, Mark Kirkwood wrote:

> Craig A. James wrote:
>
>>
>> What would be cool would be some way the developer could alter the plan,
>> but they way of doing so would strongly encourage the developer to send the
>> information to this mailing list. Postgres would essentially say, "Ok, you
>> can do that, but we want to know why!"
>>
>
> Yeah it would - an implementation I have seen that I like is where the
> developer can supply the *entire* execution plan with a query. This is
> complex enough to make casual use unlikely :-), but provides the ability to
> try out other plans, and also fix that vital query that must run today.....

hmm, I wonder if this option would have uses beyond the production hacks
that are being discussed.

specificly developers working on the optimizer (or related things like
clustered databases) could use the same hooks to develop and modify the
'optimizer' externally to postgres (doing an explain would let them find
the costs that postgres thinks each option has, along with it's
reccomendation, but the developer could try different execution plans
without having to recompile postgres between runs. and for clustered
databases where the data is split between machines this would be a hook
that the cluster engine could use to put it's own plan into place without
having to modify and recompile)

David Lang