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