(2011/12/12 22:59), Robert Haas wrote: > It does seem like this might not be enough information for the FDW to > make good decisions about pushdown. Even supposing the server on the > other hand is also PostgreSQL, the collation names might not match > (if, say, one is running Windows, and the other, Linux). And even if > they do, there is no guarantee that two collations with the same name > have the same behavior on two different machines; they probably > should, but who knows? And if we're using an FDW to talk to some > other database server, the problem is much worse; it's not clear that > we'll even begin to be able to guess whether the remote side has > compatible semantics. 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. IMO default should be false (no push down). In most cases, columns with numeric/time-related types are safe to be pushed down because they are free from collations issue, so users would want to set to true. OTOH, columns with string types would need some considerations. Once users have ensured that the column has compatible semantics, they can set "pushdown=true" for efficiency. If a condition contains any columns with pushdown=false, that condition should NOT be pushed down. This idea is only for pgsql_fdw now, but it can be used for other FDWs which support push-down, and it would be also useful for ORDER BY push-down support in future, which is apparently contains collation issue. Regards, -- Shigeru Hanada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
