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 1sve6Y-00GcCK-KW for pgsql-general@arkaria.postgresql.org; Tue, 01 Oct 2024 14:43:59 +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 1sve6Y-000NwJ-16 for pgsql-general@arkaria.postgresql.org; Tue, 01 Oct 2024 14:43:58 +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 1sve6X-000NwB-N1 for pgsql-general@lists.postgresql.org; Tue, 01 Oct 2024 14:43:57 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sve6T-0021dC-I2 for pgsql-general@lists.postgresql.org; Tue, 01 Oct 2024 14:43:57 +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 491EhqKu1831450; Tue, 1 Oct 2024 10:43:52 -0400 From: Tom Lane To: =?iso-8859-2?Q?Pecs=F6k_J=E1n?= cc: "pgsql-general@lists.postgresql.org" Subject: Re: Reading execution plan - first row time vs last row time In-reply-to: References: Comments: In-reply-to =?iso-8859-2?Q?Pecs=F6k_J=E1n?= message dated "Tue, 01 Oct 2024 13:53:18 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1831448.1727793832.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 01 Oct 2024 10:43:52 -0400 Message-ID: <1831449.1727793832@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =3D?iso-8859-2?Q?Pecs=3DF6k_J=3DE1n?=3D writes: > We see significant difference in explain analyze Actual time in the firs= t line of execution plan and Execution time in the last line of execution = plan. What can be the reason? The time reported for the top query node is just the time taken to compute all the rows returned by the query. It doesn't account for what might be done with the data afterward. A normal EXPLAIN just drops that data on the floor, so there's not much time left unaccounted-for. But if you're writing the data into a table via EXPLAIN CREATE TABLE AS, that I/O would be extra. regards, tom lane