Re: New hook after raw parsing, before analyze
От | David Beck |
---|---|
Тема | Re: New hook after raw parsing, before analyze |
Дата | |
Msg-id | A061B38D-2581-43C8-9385-A7950A71E46B@starschema.net обсуждение исходный текст |
Ответ на | Re: New hook after raw parsing, before analyze (Greg Stark <stark@mit.edu>) |
Ответы |
Re: New hook after raw parsing, before analyze
Re: New hook after raw parsing, before analyze |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: