> 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.....
So, to move on to the concrete...
I'm not familiar with the innards of Postgres except in a theoretical way. Maybe this is a totally naive or dumb
question,but I have to ask: How hard would it be to essentially turn off the optimizer?
1. Evaluate WHERE clauses left-to-right.
select ... from FOO where A and B and C;
This would just apply the criteria left-to-right, first A, then B, then C. If an index was available it would use it,
butonly in left-to-right order, i.e. if A had no index but B did, then too bad, you should have written "B and A and
C".
2. Evaluate joins left-to-right.
select ... from FOO join BAR on (...) join BAZ on (...) where ...
This would join FOO to BAR, then join the result to BAZ. The only optimization would be to apply relevant "where"
conditionsto each join before processing the next join.
3. Don't flatten sub-selects
select ... from (select ... from FOO where ...) as X where ...;
This would do the inner select then use the result in the outer select, and wouldn't attempt to flatten the query.
Thanks,
Craig
