2013/10/16 Robert Haas <robertmhaas@gmail.com>:
> On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> One reason we should support local triggers is that not all the data
>> source of FDW support remote trigger. It required FDW drivers to
>> have RDBMS as its backend, but no realistic assumption.
>> For example, file_fdw is unavailable to implement remote triggers.
>
> True, but gosh, updates via file_fdw are gonna be so slow I can't
> believe anybody'd use it for something real....
>
How about another example? I have implemented a column-oriented
data store with read/write capability, using FDW APIs.
The role of FDW driver here is to translate its data format between
column-oriented and row-oriented, but no trigger capability itself.
>> One thing I'd like to know is, where is the goal of FDW feature.
>> It seems to me, FDW goes into a feature to manage external data
>> set as if regular tables. If it is right understanding, things we try to
>> support on foreign table is things we're supporting on regular tables,
>> such as triggers.
>
> I generally agree with that.
>
>> We often have some case that we cannot apply fully optimized path
>> because of some reasons, like view has security-barrier, qualifier
>> contained volatile functions, and so on...
>> Trigger may be a factor to prevent fully optimized path, however,
>> it depends on the situation which one shall be prioritized; performance
>> or functionality.
>
> Sure. I mean, I guess if there are enough people that want this, I
> suppose I ought not stand in the way. It just seems like a lot of
> work for a feature of very marginal utility.
>
The reason why I'm interested in this feature is, row-level triggers on
foreign tables will become a piece to implement table partitioning
that contains multiple foreign tables.
Probably, it also connects to the effort of custom-plan node (in the
future) that enables to replace Append node by custom logic, to kick
multiple concurrent remote queries on behalf of partitioned foreign table.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
