Re: pgsql_fdw, FDW for PostgreSQL server
От | Albe Laurenz |
---|---|
Тема | Re: pgsql_fdw, FDW for PostgreSQL server |
Дата | |
Msg-id | D960CB61B694CF459DCFB4B0128514C2073C85B1@exadv11.host.magwien.gv.at обсуждение исходный текст |
Ответ на | Re: pgsql_fdw, FDW for PostgreSQL server (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql_fdw, FDW for PostgreSQL server
Re: pgsql_fdw, FDW for PostgreSQL server |
Список | pgsql-hackers |
Tom Lane wrote: > Shigeru Hanada <shigeru.hanada@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
В списке pgsql-hackers по дате отправления: