On Mon, Feb 9, 2015 at 2:31 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Another idea is to use Executor level interfaces (like ExecutorStart(),
> ExecutorRun(), ExecutorEnd()) for execution rather than using Portal
> level interfaces. I have used Portal level interfaces with the
> thought that we can reuse the existing infrastructure of Portal to
> make parallel execution of scrollable cursors, but as per my analysis
> it is not so easy to support them especially backward scan, absolute/
> relative fetch, etc, so Executor level interfaces seems more appealing
> to me (something like how Explain statement works (ExplainOnePlan)).
> Using Executor level interfaces will have advantage that we can reuse them
> for other parallel functionalaties. In this approach, we need to take
> care of constructing relavant structures (with the information passed by
> master backend) required for Executor interfaces, but I think these should
> be lesser than what we need in previous approach (extract seqscan specific
> stuff from executor).
I think using the executor-level interfaces instead of the
portal-level interfaces is a good idea. That would possibly let us
altogether prohibit access to the portal layer from within a parallel
worker, which seems like it might be a good sanity check to add. But
that seems to still require us to have a PlannedStmt and a QueryDesc,
and I'm not sure whether that's going to be too much of a pain. We
might need to think about an alternative API for starting the Executor
like ExecutorStartParallel() or ExecutorStartExtended(). But I'm not
sure. If you can revise things to go through the executor interfaces
I think that would be a good start, and then perhaps after that we can
see what else makes sense to do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company