> > * 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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers