I think I’m gonna need to dig into the planner to fully understand your points. Thank you for the insights. I was more
intoputting the knowledge of the legacy system into the an extension and my codebase. Now I see better use of the
plannerwould help. Thank you.
What inspired me is the scriptable query rewrite in http://dev.mysql.com/downloads/mysql-proxy/
The hook I proposed would be a lot nicer in Postgres because the raw parsing is already done at this point while in
mysql-proxythat has to be done manually.
Another point I liked in mysql is the possibility to write info schema plugins:
http://dev.mysql.com/doc/refman/5.1/en/writing-information-schema-plugins.html
Like a virtual catalog. Is there anything similar in Postgres?
Thank you, David
2014.02.14. dátummal, 18:06 időpontban Greg Stark <stark@mit.edu> írta:
> 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
