Re: Custom Scan APIs (Re: Custom Plan node) - Mailing list pgsql-hackers

From Shigeru Hanada
Subject Re: Custom Scan APIs (Re: Custom Plan node)
Date
Msg-id CAEZqfEfY=2DTudBMiW6N4bk3ziwcAnBYirPAstXEavwrOue0Dg@mail.gmail.com
Whole thread Raw
In response to Re: Custom Scan APIs (Re: Custom Plan node)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
Hi Kaigai-san,

2014-02-23 22:24 GMT+09:00 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> (1) Interface to add alternative paths in addition to built-in join paths

I found that create_custom_path is not used at all in your patch.
I revised postgresql_fdw.c to use it like this.

...   /* Create join information which is stored as private information. */   memset(&jinfo, 0,
sizeof(PgRemoteJoinInfo));  jinfo.fdw_server_oid = o_server_oid;   jinfo.fdw_user_oid = o_user_oid;   jinfo.relids =
joinrel->relids;  jinfo.jointype = jointype;   jinfo.outer_rel = o_relinfo;   jinfo.inner_rel = i_relinfo;
jinfo.remote_conds= j_remote_conds;   jinfo.local_conds = j_local_conds;
 
   /* OK, make a CustomScan node to run remote join */   cpath = create_customscan_path(root,
      joinrel,                                  0, 0, 0,     /* estimate later */                                  NIL,
                                required_outer,                                  "postgres-fdw",
         0,                                  packPgRemoteJoinInfo(&jinfo));
 
   estimate_remote_join_cost(root, cpath, &jinfo, sjinfo);
   add_path(joinrel, &cpath->path);
...

This seems to work fine.  Is this right approach?  If so,this portion
would be a good example to replace local join with custom scan for
authors of custom scan providers.  One thing I worry is the case that
you've intentionally avoided calling create_customscan_path.

-- 
Shigeru HANADA



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Minor performance improvement in transition to external sort
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: inherit support for foreign tables