Re: New hook after raw parsing, before analyze
От | Greg Stark |
---|---|
Тема | Re: New hook after raw parsing, before analyze |
Дата | |
Msg-id | CAM-w4HMYup0ZH0o8H3qr++iZwLG73zXw+1KeTtuMkwwLtEyMzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New hook after raw parsing, before analyze (David Beck <dbeck@starschema.net>) |
Ответы |
Re: New hook after raw parsing, before analyze
|
Список | pgsql-hackers |
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 по дате отправления: