Tom Lane wrote: > Shigeru Hanada <shigeru.han...@gmail.com> writes: >> (2011/12/12 22:59), Robert Haas wrote: >>> ... I feel like we might need a system here that >>> allows for more explicit user control about what to push down vs. not, >>> rather than assuming we'll be able to figure it out behind the scenes.
>> Agreed. How about to add a per-column boolean FDW option, say >> "pushdown", to pgsql_fdw? Users can tell pgsql_fdw that the column can >> be pushed down safely by setting this option to true. > [ itch... ] That doesn't seem like the right level of granularity. > ISTM the problem is with whether specific operators have the same > meaning at the far end as they do locally. If you try to attach the > flag to columns, you have to promise that *every* operator on that > column means what it does locally, which is likely to not be the > case ever if you look hard enough. Plus, having to set the flag on > each individual column of the same datatype seems pretty tedious. > > I don't have a better idea to offer at the moment though. Trying > to attach such a property to operators seems impossibly messy too. > If it weren't for the collations issue, I might think that labeling > datatypes as being compatible would be a workable approximation. Maybe I'm missing something, but if pushdown worked as follows: - Push down only system functions and operators on system types. - Only push down what is guaranteed to work. then the only things we would miss out on are encoding- or collation-sensitive string operations. Is that loss so big that it warrants a lot of effort? Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers