Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1onKJ6-000245-29 for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Oct 2022 13:49:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1onKJ3-0000Lq-EW for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Oct 2022 13:49:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1onKJ3-0000Lh-2Z for pgsql-hackers@lists.postgresql.org; Tue, 25 Oct 2022 13:49:25 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1onKJ0-0005OX-2M for pgsql-hackers@lists.postgresql.org; Tue, 25 Oct 2022 13:49:24 +0000 Received: by mail-ej1-x634.google.com with SMTP id t25so7115209ejb.8 for ; Tue, 25 Oct 2022 06:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=iPB/MXCU1+ffOU093+9DyWJdVyAF/Nv4cXXiobdiM0s=; b=sEyQ1SpV3HnSp70eUWvPPTIadQsJ5MWRTZky9gFJ3wrJaJeb3cM2Sz+mGiUPM0jKd6 b4Ca0JFJV4ubbPypIxC7gBSlJ9cyqHrXlWsZXTaooYb1VVVUcKeq2KBhFwYi9kLE3wND k5VCxFS+wBuNccL7yw6cEFM7pjID6KfpPStUQr7uRMD9ZcBgtMbwxEFJczd7ePkp3rR6 NymsQDYSPX0TYSm7xTJFUnYyOcH5U9HUMGUAogcVe96dH8vslpPa5Gun4Ir8gh8SKaMd i9ev5ldIYThNV1WT6gfMGRDFmqoGVCsLIgwxgWNmjNKtFnG04Ij75+DI/CBtWIIRXygI zKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=iPB/MXCU1+ffOU093+9DyWJdVyAF/Nv4cXXiobdiM0s=; b=wfK4e/a7w3Jv/IBZOeg9S2MJidu0ULIsLrmfxQmI9PHwtrSfsnHi5Q6ISLpkwL2+t4 vVXaP30TYpeVcUGvYke3KpKRIlNaYUhSV61curXRHX9qFjn4b+jRJ3QZdZCLG8tkrfUg JKqEwdx3lcNZ1D2V/FNbF69Ib/a5oADl+ZMhmH7pdM5NofPbqkSzYPcbv3HWWULDCL5F N/R2NLQmyx5vGaCg3hVtwqsv/3uIluK9urWJ5k6PWPbjLtYpP3rZRrl26qFsYK94QeBM mnhXBd5VNWn6dH2QQIv1r3nWX7Y44+zuIOs1xd/73H2Asc4Y0AerUwbBQSYNNPh1/MaP rGqw== X-Gm-Message-State: ACrzQf2D/ZAnGt7jXvoQM76vUyKg5TdvY8GuHdsohO7PR1O9yjJBCjmb g+ynckXHhC+r7/ta2KvnJMXglw== X-Google-Smtp-Source: AMsMyM6x+mVBgjcElqZIoJpILgPzP9ONUYDjHQ7eFdT9+u4aBohr6PyO6r0z+Rx4hffu3RFJfZ6+Jg== X-Received: by 2002:a17:907:720e:b0:78e:2b59:fdf1 with SMTP id dr14-20020a170907720e00b0078e2b59fdf1mr33601364ejc.659.1666705759639; Tue, 25 Oct 2022 06:49:19 -0700 (PDT) Received: from localhost.localdomain ([46.183.103.8]) by smtp.gmail.com with ESMTPSA id m15-20020a50ef0f000000b00458824aee80sm1687681eds.38.2022.10.25.06.49.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Oct 2022 06:49:19 -0700 (PDT) Message-ID: <033ff31aeeb5d0bb49a8e85df32d34e032ab5729.camel@cybertec.at> Subject: Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE)) From: Laurenz Albe To: Justin Pryzby , "David G. Johnston" Cc: Nikolay Samokhvalov , pgsql-hackers@lists.postgresql.org Date: Tue, 25 Oct 2022 15:49:14 +0200 In-Reply-To: <20221021020934.GA13372@telsasoft.com> References: <20211115190954.GO17618@telsasoft.com> <20211202005820.GJ17618@telsasoft.com> <20220124173548.GV23027@telsasoft.com> <20220905112031.GF31833@telsasoft.com> <20221021020934.GA13372@telsasoft.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2022-10-20 at 21:09 -0500, Justin Pryzby wrote: > Rebased. I had a look at the patch set. It applies and builds cleanly and passes the regression tests. 0001: Add GUC: explain_regress I like the idea of the "explain_regress" GUC. That should simplify the regression tests. --- a/src/test/regress/pg_regress.c +++ b/src/test/regress/pg_regress.c @@ -625,7 +625,7 @@ initialize_environment(void) * user's ability to set other variables through that. */ { - const char *my_pgoptions = "-c intervalstyle=postgres_verbose"; + const char *my_pgoptions = "-c intervalstyle=postgres_verbose -c explain_regress=on"; const char *old_pgoptions = getenv("PGOPTIONS"); char *new_pgoptions; @@ -2288,6 +2288,7 @@ regression_main(int argc, char *argv[], fputs("log_lock_waits = on\n", pg_conf); fputs("log_temp_files = 128kB\n", pg_conf); fputs("max_prepared_transactions = 2\n", pg_conf); + // fputs("explain_regress = yes\n", pg_conf); for (sl = temp_configs; sl != NULL; sl = sl->next) { This code comment is a leftover and should go. 0002: exercise explain_regress This is the promised simplification. Looks good. 0003: Make explain default to BUFFERS TRUE Yes, please! This patch is independent from the previous patches. I'd like this to be applied, even if the GUC is rejected. (I understand that that would cause more changes in the regression test output if we changed that without introducing "explain_regress".) The patch changes the default value of "auto_explain.log_buffers" to "on", which makes sense. However, the documentation in doc/src/sgml/auto-explain.sgml should be updated to reflect that. --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -731,8 +731,8 @@ EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)'; - EXPLAIN has a BUFFERS option that can be used with - ANALYZE to get even more run time statistics: + EXPLAIN ANALYZE has a BUFFERS option which + provides even more run time statistics: EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000; This is not enough. The patch would have to update all the examples that use EXPLAIN ANALYZE. I see two options: 1. Change the output of all the examples and move this explanation to the first example with EXPLAIN ANALYZE: The numbers in the Buffers: line help to identify which parts of the query are the most I/O-intensive. 2. Change all examples that currently do *not* use BUFFERS to EXPLAIN (BUFFERS OFF). Then you could change the example that shows BUFFERS to something like If you do not suppress the BUFFERS option that can be used with EXPLAIN (ANALYZE), you get even more run time statistics: 0004, 0005, 0006, 0007: EXPLAIN (MACHINE) I think it is confusing that these are included in this patch set. EXPLAIN (MACHINE OFF) is similar to "explain_regress = on", only it goes even further: no query ID, no Heap Fetches, no Sort details, ... Why not add this functionality to the GUC? 0005 suppresses "rows removed by filter", but how is that machine dependent? > BTW, I think it may be that the GUC should be marked PGDLLIMPORT ? I think it is project policy to apply this mark wherever it is needed. Do you think that third-party extensions might need to use this in C code? Yours, Laurenz Albe