"Curtis Faith" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
