On Fri, 5 Nov 2010 16:27:49 +0900
Itagaki Takahiro <itagaki.takah...@gmail.com> wrote:
> On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA
> <han...@metrosystems.co.jp> wrote:
> >> > * am_beginscan()        -> first call of FdwRoutine.Iterate()?
> >> It might be good to have a separated "beginscan" method if we use
> >> asynchronous scans in multiple foreign servers in one query
> >
> > You mean that separated beginscan (FdwRoutine.BeginScan?) starts
> > asynchronous query and returns immediately, and FdwRoutine.Iterate
> > returns result of that query?
> 
> Yes. Each BeginScan() in the executor node tree will be called at
> the beginning of executor's run. The callback should not block
> the caller. OTOH, Iterate() are called at the first time tuples
> in the node are required.

Thanks, now I see your point.  Current FdwRoutine has no appropriate
function because Open is called from ExecutorStart which is used by
EXPLAIN too.

But then we have mismatch between executor node interface and FDW
interface about BeginScan.  Should we add new function such as
ExecBeginNode and call ExecBeginXXX for each plan node?

New Query Processing Control Flow would be:
# based on README of executor directory

    CreateQueryDesc

    ExecutorStart
        CreateExecutorState
            creates per-query context
        switch to per-query context to run ExecInitNode
        ExecInitNode --- recursively scans plan tree
            CreateExprContext
                creates per-tuple context
            ExecInitExpr

    ExecutorRun
        ExecBeginNode(new) --- recursively scans plan tree
            call ExecBeginXXXS for each plan node
        ExecProcNode --- recursively called in per-query context
            ExecEvalExpr --- called in per-tuple context
            ResetExprContext --- to free memory

    ExecutorEnd
        ExecEndNode --- recursively releases resources
        FreeExecutorState
            frees per-query context and child contexts

    FreeQueryDesc

> PL/Proxy has a similar functionality with RUN ON ALL to start queries
> in parallel. So, I think it's a infrastructure commonly required.
I noticed the lack of consideration about cache invalidation from
reading PL/Proxy source, thanks for your mention about PL/Proxy. :-)

Regards,
--
Shigeru Hanada



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to