Refactor for optimizer

[coocood]

Optimizer need to know everything to do the job, like transform the statement/expression, choose best index to use. But currently the only optimization work is done inside plan.Fillter method, which is not capable for the job because a plan knows nothing more than itself.

The execution flow can be seperated in three stages.

prepare

Validate the statement is legal, make sure table and identifier reference does exists, etc.

optimize

Transform the statement into optimized and normalized form and choose index to use.

execute

Do execution.

Currently the execution is performed directly in Statment.Exec method, as a result, the stmts package imports a lot of dependencies, makes it hard to be imported by other packages.

We have difficulty in doing optimisation right now because of cyclic import restriction.

plans and rsets can not import stmts.

So the proposal is to move the execution functionality out of stmt/stmts package, add a new exec package and do the optimisation and execution work there. So stmt/stmts only keeps basic functionality and can be imported by plans.

The result dependency relation is going to be:

expression -> stmts -> plans -> rsets -> exec

Plan interface and Statement interface and their implmentations are going to be in the same package, this also makes it easier to apply visitor pattern.

[siddontang]

what's the structure for PostgreSQL?
Maybe we can refer it.

[coocood]

There are many SQL projects, all of them have execution code separated from statements.
We can just extract Exec first, then we can decide how to do optimisation later.

[ngaut]

LGTM, We could move step by step.