Let me rephrase this: Let’s remove my motivations and use cases from this conversation….
Why is that a bad idea of rewriting the query before it reaches transform/analyze (without ever accessing the catalog)? If that flexibility is acceptable to you, where would be the best place to put it in? Thanks, David 2014.02.14. dátummal, 10:30 időpontban David Beck <db...@starschema.net> írta: > Thanks for the reply. There are two things I think I’ve been misunderstood: > > 1, the point is to do the rewrite without and before catalog access > 2, I do want to push the join to the source and equally important pushing the > where conditions there > > Best regards, David > > > 2014.02.13. dátummal, 21:22 időpontban Tom Lane <t...@sss.pgh.pa.us> írta: > >> David Beck <db...@starschema.net> writes: >>> I have table like data structures in the source system for the FDW I work >>> on. >>> These tables are sometimes too big and the source system is able to filter >>> and join them with limitations, thus it is not optimal to transfer the data >>> to Postgres. >>> At the same time I want the users to think in terms of the original tables. >> >>> The idea is to rewrite the SQL queries like this: >> >>> “SELECT * FROM tableA a, tableB b WHERE a.id=b.id AND a.col1=1234 AND >>> b.col2=987” >> >>> to: >> >>> “SELECT * FROM fdw_tableA_tableB ab WHERE ab.col1=1234 AND ab.col2=987” >> >> TBH this sounds like a spectacularly bad idea, especially in the place and >> way you propose to do it. You can't even do catalog access safely where >> you've put that hook, not to mention that there are many other places >> where queries can be submitted. But more generally, an FDW should not >> operate in the way you're describing. >> >> We do lack support for pushing joins to the foreign server, and that needs >> to be addressed; but we need to do it in the planner, not by kluging the >> query somewhere upstream of that. >> >> regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
