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 1t2DUQ-002UpO-T7 for pgsql-general@arkaria.postgresql.org; Sat, 19 Oct 2024 17:43:47 +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 1t2DUO-005lV5-LU for pgsql-general@arkaria.postgresql.org; Sat, 19 Oct 2024 17:43:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t2DUO-005lUx-6J for pgsql-general@lists.postgresql.org; Sat, 19 Oct 2024 17:43:44 +0000 Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t2DUL-001vzH-Py for pgsql-general@postgresql.org; Sat, 19 Oct 2024 17:43:43 +0000 Received: by mail-ed1-x543.google.com with SMTP id 4fb4d7f45d1cf-5c99be0a4bbso4248491a12.2 for ; Sat, 19 Oct 2024 10:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729359821; x=1729964621; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mph/qI9lFYUmJDbPnEIQNZEB8qxmuvF7Tea+MMmlq4w=; b=d0uWQcOzORbaXNsOw2UvDiVaFMRz7wOPj9SyhWLXxj70TmfLVf+fPxb+a/y9figMX3 qGolEfi/99F1OFnpBOMy9rJ6qjix6YJWJ7U143Z4aYTF1fzjklg+Up+iDmSOkDEipjsq DWSGfmsJgthWkLuH/HCQ6HO+wN/ylRysHCrNRR7IOhPsTElUCx/JirBxR+YDAeCXLP2I kk4f2pKVf550a7MWjR/7zr7d6AIsn0CNeDXNfvD4RBR3lpVZMXM8mCl2EnkZWQQleoUn BwdcQS3gJNzSpW8Pt4WbB4JrkRLQCgQkpJiAa8/+a5n7yvNgqms1b9svvpYek6sd7GNu YbPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729359821; x=1729964621; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mph/qI9lFYUmJDbPnEIQNZEB8qxmuvF7Tea+MMmlq4w=; b=lZPzEJ1dM8S7bIsWCYad/IZuKSAbp+RT+VxN81EDMqUOeKJtDYjMHjthuMEwZiqZT9 wb52G0BXeoPp7aELlPprDoRF0MR8gC+xQqJgIcY8A14u0wNRFdk+MU5hcOy8O09BeerK RklSLM606wb+hk0KqAaEVsVuijkDjQvAl5jVIdRYVcsgBIZquVj8jMV7JoflM49NivFk SjMoCNVQdvzO/BWoVPB5ux9eVpn+VFT7L6JMaP1h93u+r8DU+uKXIWde8zD0gSmbUKht wW3wG7CZ8fDTxhFaHIMFzKYgX2vx8DwudHF53YfinOFbCCbJADSZNZuCUvBSf1dIqBEd vuMQ== X-Gm-Message-State: AOJu0YzLrDPXEx3mpgbahGBahxNqGpCz1o2ZCOInCxtI+UpksgXtayYW mN6rN0ROYB0WYqqVa86/9wuRdU4Ua7pZAwO6wc3zUSwmObXUi544x6a9GzfnCSl95WCoHyTzPi1 iXVtHVPxPqKyvsH86NO6PhXK2xrwVT4kAh4M= X-Google-Smtp-Source: AGHT+IGhrm09/UVStkxBZZPUHQmdxpvlUgrUThtqPNpTHbq1shisg9ghJmpe7m/2FwswZaJRlgmqFUmjxf6GIWavZ+A= X-Received: by 2002:a17:906:db08:b0:a99:5234:c56c with SMTP id a640c23a62f3a-a9a69ba5cf8mr550016966b.33.1729359820666; Sat, 19 Oct 2024 10:43:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijaykumar Jain Date: Sat, 19 Oct 2024 23:13:31 +0530 Message-ID: Subject: Re: explain vs auto_explain To: "David G. Johnston" Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000ccc3250624d7f5e3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ccc3250624d7f5e3 Content-Type: text/plain; charset="UTF-8" On Sat, 19 Oct 2024 at 22:55, David G. Johnston wrote: > > With auto_explain you end up producing multiple individual explains, one > for each top-level query being executed. Each one produced by auto_explain > which hooks into the point where a top-level query begins execution. > Running explain directly on a top-level query doesn't establish any of the > needed hooks to produce these additional explains. While those hooks could > be installed the output for manual explain is the single query result sent > to the client. How multiple explains could be combined into that single > output channel would need to be figured out as well. While auto_explain > uses the log file which is much simpler to use in this manner since each > auto_explain can just be told to write its output to the log and not worry > about any other considerations. > > Thanks David. The reason is, a normal db user who does not have access to logs or the db server, will rely on what the console throws back. as a result, they are not able to get the complete view of what is happening ... not sure how relevant is this context, but when i was playing with citus, they have a flag set citus.explain_all_tasks = 1; which is session based and dumps the plan on all remote workers / shard nodes right to the user, which otherwise only dumps for one node .. yes its verbose, but it helps the user to see what was run on the shard. Similarly, I was expecting to explain to give a full plan with nested plans if requested back to the user in their session directly. if they dont want the extended output, the default flags should be fine ? Or is it the case, where there can be million rows from remote tables, and auto_explain will log all scans for all matching rows, thereby killing the console session or something ? i tried to check the code for auto_explain , there is nothing that helps understand why it was provided as a separate . -- Thanks, Vijay Open to work Resume - Vijaykumar Jain --000000000000ccc3250624d7f5e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 19 Oct 2024 at 2= 2:55, David G. Johnston <d= avid.g.johnston@gmail.com> wrote:

With auto_explain you end up producing multiple individual explai= ns, one for each top-level query being executed.=C2=A0 Each one produced by= auto_explain which hooks into the point where a top-level query begins exe= cution.=C2=A0 Running explain directly on a top-level query doesn't est= ablish any of the needed hooks to produce these additional explains.=C2=A0 = While those hooks could be installed the output for manual explain is the s= ingle query result sent to the client.=C2=A0 How multiple explains could be= combined into that single output channel would need to be figured out as w= ell.=C2=A0 While auto_explain uses the log file which is much simpler to us= e in this manner since each auto_explain can just be told to write its outp= ut to the log and not worry about any other considerations.

Thanks David.
The reason is, a normal db user who does n= ot have access to logs or the db server, will rely on what the console thro= ws back.
=C2=A0as a result, they are not able to get the complete= view of what is happening ...=C2=A0

not sure how = relevant is this context, but when i was playing with citus, they have a fl= ag
set citus.explain_all_tasks =3D 1;=C2=A0
which is se= ssion based and dumps the plan on all remote workers / shard nodes right to= the user, which otherwise only dumps for one node .. yes its verbose, but = it helps the user to see what was run on the shard.

Similarly, I was expecting to explain to give a full plan with nested pla= ns if requested back to the user in their session directly. if they dont wa= nt the extended output, the default flags should be fine ?=C2=A0
= Or is it the case, where there can be million rows from remote tables, and = auto_explain will log all scans for all matching rows, thereby killing the = console session or something ?
i tried to check the code for auto= _explain , there is nothing that helps understand why it was provided as a = separate .


=C2=A0
--
Thanks,
Vijay

= Open to work
Resume -=C2=A0Vijaykumar Jain
--000000000000ccc3250624d7f5e3--