Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t2Dm6-002WD5-CK for pgsql-general@arkaria.postgresql.org; Sat, 19 Oct 2024 18:02:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t2Dm4-0060pi-My for pgsql-general@arkaria.postgresql.org; Sat, 19 Oct 2024 18:02:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t2Dm4-0060pV-6A for pgsql-general@lists.postgresql.org; Sat, 19 Oct 2024 18:02:00 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t2Dm1-001jEW-JL for pgsql-general@postgresql.org; Sat, 19 Oct 2024 18:01:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 49JI1u7f1128628; Sat, 19 Oct 2024 14:01:56 -0400 From: Tom Lane To: "David G. Johnston" cc: Vijaykumar Jain , pgsql-general Subject: Re: explain vs auto_explain In-reply-to: References: Comments: In-reply-to "David G. Johnston" message dated "Sat, 19 Oct 2024 10:50:01 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1128626.1729360916.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sat, 19 Oct 2024 14:01:56 -0400 Message-ID: <1128627.1729360916@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Sat, Oct 19, 2024 at 10:43 AM Vijaykumar Jain < > vijaykumarjain.github@gmail.com> wrote: >> i tried to check the code for auto_explain , there is nothing that helps >> understand why it was provided as a separate . > Probably because output to log was easier than reworking the internals to > make output to client happen. The reason that auto_explain exists is to capture plans for queries that are being issued by real applications --- which aren't programmed to issue EXPLAIN for themselves, and likely don't have a good place to put the data if they did. Also, auto_explain can capture runtime details for queries that are really being executed and delivering results, whereas EXPLAIN ANALYZE doesn't deliver the query results and thus can't be shoehorned into real applications. So it's partly a matter of not having a protocol spec that would allow the EXPLAIN data to be delivered on a side channel, but mostly a recognition that rewriting applications to capture such data would be painful. regards, tom lane