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, but only 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" conditions to 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
