Re: Triaging the remaining open commitfest items

> > * ctidscan as an example of custom-scan
> >
> > This basically hasn't gotten any attention, which may mean nobody cares
> > enough to justify putting it in the tree.  We need to either push it to
> > next CF or reject altogether.
> 
> Agreed.  I was fine with never committing this.  I don't think we have
> a requirement that every hook or bit of functionality we expose at the
> C level must have an example in core.  But other people (you?  Simon?)
> seemed to want a demonstration in the core repository.  If that's
> still a priority, I am willing to work on it more for 9.6, but there
> is not time now.
>
If no other people required it again, I don't think this module should
be kept in core and also I'm not favor to push ctidscan to v9.6 development
cycle. It intends to demonstrate custom-scan interface, however, it is
not certain an example always needs to be in-core.
If we split the patch partially, definition below makes sense to implement
out-of-core example module

+#define TIDNotEqualOperator    402DATA(insert OID = 2799 (  "<"     PGNSP PGUID b f f    27      27      16
2800DESCR("lessthan");#define TIDLessOperator    2799DATA(insert OID = 2800 (  ">"     PGNSP PGUID b f f    27      27
   16 2799DESCR("greater than");
 
+#define TIDGreaterOperator     2800DATA(insert OID = 2801 (  "<="    PGNSP PGUID b f f    27      27      16
2802DESCR("lessthan or equal");
 
+#define TIDLessEqualOperator   2801DATA(insert OID = 2802 (  ">="    PGNSP PGUID b f f    27      27      16
2801DESCR("greaterthan or equal");
 
+#define TIDGreaterEqualOperator        2802

> > * Join pushdown support for foreign tables
> >
> > There doesn't seem to be any current patch linked to this CF item.
> > If there is a patch to get postgres_fdw to make use of the recently
> > committed join-path support, I assume it's in need of a rebase anyway.
> 
> I think there is a rebased patch around.  I think it's just not linked
> into the CF thread.  I don't think it's committable as is.
>
I believe he is working to follow up the latest foreign/custom-join
interface on which postgres_fdw expected. One point we like to clarify
is how create_plan_recurse() shall be dealt with.
As Hanada-san posted yesterday, postgres_fdw internally uses
create_plan_recurse() to fetch SQL statement associated with inner /
outer sub-plan, so it will take additional adjustment work even
though he already begin to work.

| IMO it isn't necessary to apply the change onto
| ForeignPath/ForeignScan.  FDW would have a way to keep-and-use sub
| paths as private information.  In fact, I wrote postgres_fdw to use
| create_plan_recurse to generate SQL statements of inner/outer
| relations to be joined, but as of now SQL construction for join
| push-down is accomplished by calling private function deparseSelectSql
| recursively at the top of a join tree.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>