Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hO8Ef-0000KM-05 for pgsql-hackers@arkaria.postgresql.org; Tue, 07 May 2019 22:06:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hO8Ed-00079r-Nb for pgsql-hackers@arkaria.postgresql.org; Tue, 07 May 2019 22:06:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hO8Ed-00078l-ER for pgsql-hackers@lists.postgresql.org; Tue, 07 May 2019 22:06:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hO8Eb-0002uv-8p for pgsql-hackers@postgresql.org; Tue, 07 May 2019 22:06:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x47M6hKa004639; Tue, 7 May 2019 18:06:43 -0400 From: Tom Lane To: Andres Freund cc: David Fetter , PostgreSQL Development Subject: Re: New EXPLAIN option: ALL In-reply-to: <20190507215449.3a4yb5kkoloq7yyw@alap3.anarazel.de> References: <20190507073046.GI28936@fetter.org> <20190507154147.l32a3erg4mbycj7u@alap3.anarazel.de> <20190507163411.GM28936@fetter.org> <20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de> <20190507212355.GQ28936@fetter.org> <20190507215449.3a4yb5kkoloq7yyw@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 07 May 2019 14:54:49 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4637.1557266803.1@sss.pgh.pa.us> Date: Tue, 07 May 2019 18:06:43 -0400 Message-ID: <4638.1557266803@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > As I said, I don't think ALL is a good idea under any name. Like it > just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS, > SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's > several separate axis (query is executed or not (ANALYZE), verbosity > (SUMMARY, VERBOSE), collecting additional information (BUFFERS, TIMING), > output format). FWIW, I find this line of argument fairly convincing. There may well be a case for rethinking just how EXPLAIN's options behave, but "ALL" doesn't seem like a good conceptual model. One idea that comes to mind is that VERBOSE could be redefined as some sort of package of primitive options, including all of the "additional information" options, with the ability to turn individual ones off again if you wanted. So for example (VERBOSE, BUFFERS OFF) would give you everything except buffer stats. We'd need a separate flag/flags to control what VERBOSE originally did, but that doesn't bother me --- it's an opportunity for more clarity of definition, anyway. I do feel that it's a good idea to keep ANALYZE separate. "Execute the query or not" is a mighty fundamental thing. I've never liked that name for the option though --- maybe we could deprecate it in favor of EXECUTE? regards, tom lane