I think I’m gonna need to dig into the planner to fully understand your points.
Thank you for the insights. I was more into putting the knowledge of the legacy
system into the an extension and my codebase. Now I see better use of the
planner would help. Thank you.
What inspired me is the scriptable query rewrite in
The hook I proposed would be a lot nicer in Postgres because the raw parsing is
already done at this point while in mysql-proxy that has to be done manually.
Another point I liked in mysql is the possibility to write info schema plugins:
Like a virtual catalog. Is there anything similar in Postgres?
Thank you, David
2014.02.14. dátummal, 18:06 időpontban Greg Stark <st...@mit.edu> írta:
> 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?
> 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.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: