From: | Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgsql_fdw, FDW for PostgreSQL server |
Date: | 2011-11-28 11:00:23 |
Message-ID: | 4ED369C7.20807@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Kaigai-san,
(2011/11/20 2:42), Kohei KaiGai wrote:
> I'm still under reviewing of your patch, so the comment is not overall, sorry.
Thanks for the review!
> 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.
I agree that allowing users to control which function/operator should be
pushed down is useful, but GUC seems too large as unit of switching
behavior. "Routine Mapping", a mechanism which is defined in SQL/MED
standard, would be the answer for this issue. It can be used to map a
local routine (a procedure or a function) to something on a foreign
server. It is like user mapping, but it has mapping name. Probably it
would have these attributes:
pg_catalog.pg_routine_mapping
rmname name
rmprocid regproc
rmserverid oid
rmfdwoptions text[]
If we have routine mapping, FDW authors can provide default mappings
within extension installation, and users can customize them. Maybe FDWs
will want to push down only functions/operators which have routine
mapping entries, so providing common routine which returns mapping
information of given function/operator, say GetRoutineMapping(procid,
serverid), is useful.
Unfortunately we don't have it at the moment, I'll fix pgsql_fdw so that
it pushes down only built-in operators, including scalar-array operators.
Regards,
--
Shigeru Hanada
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Urbański | 2011-11-28 11:09:44 | Re: splitting plpython into smaller parts |
Previous Message | Alexander Shulgin | 2011-11-28 10:55:36 | Re: Notes on implementing URI syntax for libpq |