Re: enable_joinremoval
От | Robert Haas |
---|---|
Тема | Re: enable_joinremoval |
Дата | |
Msg-id | 603c8f071003290829r1f41609cs1d5c35b19fcb47bc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: enable_joinremoval (Jaime Casanova <jcasanov@systemguards.com.ec>) |
Ответы |
Re: enable_joinremoval
|
Список | pgsql-hackers |
On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova <jcasanov@systemguards.com.ec> wrote: > On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: >> >> It seems that what's really needed is some debug output to be able to >> find out what it did. > > +1, i was preparing an env for testing this but in the while i was > thinking how can i know what happens... counting the tables in the > explain analyze? it's possible but not ideal I don't actually see much value in making EXPLAIN show which tables were removed. The usefulness of doing that presumes that the user is asking a particular and very specific question, namely, exactly which tables got removed?, or perhaps, did this particular table get removed? The latter question is not too hard to figure out anyway - just look for that table in the query. The former is a little harder but if you really need to know you can always look at which tables WERE referenced and work backwards from there, or write a little script to post-process the JSON, XML, or YAML output. Of course sometimes it would be handy to have but if we start adding too many bells and whistles to the EXPLAIN output it will get cluttered and unuseful. I think the value of an enable_joinremoval switch is that it lets someone throw the switch and see how the plan changes. It might change in a very simple way or it might have a dramatic effect on the whole plan. ...Robert
В списке pgsql-hackers по дате отправления: