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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
