Re: pgsql_fdw, FDW for PostgreSQL server

Hanada-san,

I'm still under reviewing of your patch, so the comment is not overall, sorry.

I'm not sure whether the logic of is_foreign_expr() is appropriate.
It checks oid of the function within FuncExpr and OpExpr to disallow to push
down user-defined functions.
However, if a user-defined operator is implemented based on built-in functions
with different meaning, is it really suitable to push-down?
E.g) It is available to define '=' operator using int4ne, even though
quite nonsense.
So, I'd like to suggest to check oid of the operator; whether it is a
built-in, or not.

On the other hand, this hard-wired restriction may damage to the purpose of
this module; that enables to handle a query on multiple nodes in parallel.
I'm not sure whether it is right design that is_foreign_expr() returns false
when the supplied expr contains mutable functions.

Probably, here are two perspectives. The one want to make sure functions works
with same manner in all nodes. The other want to distribute processing
of queries
as possible as we can. Here is a trade-off between these two perspectives.
So, how about an idea to add a guc variable to control the criteria of
pushing-down.

Thanks,

2011年11月15日17:55 Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>:
> Hi,
>
> Attached are revised version of pgsql_fdw patches.
>
> fdw_helper_funcs_v2.patch provides some functions which would be useful
> to implement FDW, and document about FDW helper functions including
> those which exist in 9.1. They are not specific to pgsql_fdw, so I
> separated it from pgsql_fdw patch.
>
> pgsql_fdw_v4.patch provides a FDW for PostgreSQL. This patch requires
> fdw_helper_funcs_v2.patch has been applied. Changes done since last
> version are:
>
> * Default of fetch_count option is increased to 10000, as suggested by
> Pavel Stehule.
> * Remove unnecessary NULL check before PQresultStatus.
> * Evaluate all conditions on local side even if some of them has been
> pushed down to remote side, to ensure that results are correct.
> * Use fixed costs for queries which contain external parameter, because
> such query can't be used in EXPLAIN command.
>
> Regards,
> --
> Shigeru Hanada
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>