Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 4BA6C633305 for ; Mon, 29 Mar 2010 12:32:45 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 99530-04-2 for ; Mon, 29 Mar 2010 15:32:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mail.postgresql.org (Postfix) with ESMTP id C13CE6338AD for ; Mon, 29 Mar 2010 12:29:26 -0300 (ADT) Received: by fxm25 with SMTP id 25so113969fxm.3 for ; Mon, 29 Mar 2010 08:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=fibYh9tSqtkHZUulP8HkWfT3uuPLP64el2vs7A3J8Qc=; b=K12ftyKpfonbi+EgJkgzwbdQcTTXhxOEKhVJprIZ8TkrdSRB0X56eCcHoGlk7NEf38 SfWv4WThfjXs2GWmVUKzmDjGOlsIzHbXIfTdGz3m5sf9awjR0C0Z+ZIoQV8tGgZLl4Rj nZfWvZF1itegv5zykQiTmbBEVidgbj1VMuG44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s+CYdc41HgY8VLU4NYIirV8NK/Gg7KmrstpP7t3hlSo3joevcquZ8yC4YRpiz622UT C7J4ec5jK1PKrnQnqBRgVQhq8wCMs8XKNCowzyHVbbHJUq0fe3kWHYarDdooG9gSrsw0 7oWy88qH4Ms2fUnCj1wwcatwiABVaIDrzPcek= MIME-Version: 1.0 Received: by 10.239.161.83 with HTTP; Mon, 29 Mar 2010 08:29:25 -0700 (PDT) In-Reply-To: <3073cc9b1003290823g52615893j8183d6e70fb510d6@mail.gmail.com> References: <1269851630.3684.3636.camel@ebony> <603c8f071003290637q14d431f7j90afabd6fd2ec952@mail.gmail.com> <12679.1269873374@sss.pgh.pa.us> <20100329144219.GA3925@alvh.no-ip.org> <3073cc9b1003290823g52615893j8183d6e70fb510d6@mail.gmail.com> Date: Mon, 29 Mar 2010 11:29:25 -0400 Received: by 10.239.171.135 with SMTP id w7mr484263hbe.56.1269876565646; Mon, 29 Mar 2010 08:29:25 -0700 (PDT) Message-ID: <603c8f071003290829r1f41609cs1d5c35b19fcb47bc@mail.gmail.com> Subject: Re: enable_joinremoval From: Robert Haas To: Jaime Casanova Cc: Alvaro Herrera , Tom Lane , Simon Riggs , pgsql-hackers@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.481 tagged_above=-10 required=5 tests=AWL=0.118, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/1147 X-Sequence-Number: 159923 On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova wrote: > On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera > 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