Re: Threaded Sorting

"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