"Curtis Faith" <curtis@galtair.com> writes:
> What about splitting out parsing, optimization and plan generation from
> execution and having a separate pool of exececutor processes.
> As an optimizer finished with a query plan it would initiate execution
> by grabbing an executor from a pool and passing it the plan.
So different executors would potentially handle the queries from a
single transaction? How will you deal with pushing transaction-local
state from one to the other?
Even if you restrict it to switching at transaction boundaries, you
still have session-local state (at minimum user ID and SET settings)
to worry about.
Being able to apply multiple CPUs to a single query is attractive,
but I've not yet seen schemes for it that don't look like the extra
CPU power would be chewed up in overhead :-(.
regards, tom lane
