On Mon, Feb 9, 2015 at 2:31 AM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers