On Fri, Feb 14, 2014 at 2:28 PM, David Beck <dbeck@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?
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
