2013/10/16 Robert Haas <robertmh...@gmail.com>: > On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
