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 402
DATA(insert OID = 2799 ( "<" PGNSP PGUID b f f 27 27 16 2800
DESCR("less than");
#define TIDLessOperator 2799
DATA(insert OID = 2800 ( ">" PGNSP PGUID b f f 27 27 16 2799
DESCR("greater than");
+#define TIDGreaterOperator 2800
DATA(insert OID = 2801 ( "<=" PGNSP PGUID b f f 27 27 16 2802
DESCR("less than or equal");
+#define TIDLessEqualOperator 2801
DATA(insert OID = 2802 ( ">=" PGNSP PGUID b f f 27 27 16 2801
DESCR("greater than 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(at)ak(dot)jp(dot)nec(dot)com>