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.
> -- 
> greg

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to