On Fri, Feb 14, 2014 at 2:28 PM, David Beck <db...@starschema.net> wrote: > 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?
Advertising
Well if there are two foreign tables and the planner could push the join work down to the fdw then the planner should be able to accurately represent that plan and cost it without having the user have to create any catalog structures. That's what the planner does for every other type of plan node. What you're describing would still be useful for materialized views. In that case the user is creating the materialized view and it is a real thing in the catalogs that won't disappear on the planner. Even then it would be ideal if the planner could decide to use the materialized view late enough that it can actually determine if it's superior rather than rewriting the query before it gets to that point. That would be much more flexible for users too who might not write the query in a way that exactly matches the materialized view. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
