From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Curtis Faith" <curtis(at)galtair(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Threaded Sorting |
Date: | 2002-10-06 00:48:31 |
Message-ID: | 6657.1033865311@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Curtis Faith" <curtis(at)galtair(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-10-06 05:37:31 | Re: Proposed LogWriter Scheme, WAS: Potential Large |
Previous Message | Tom Lane | 2002-10-06 00:25:35 | Re: New lock types |