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 1sr4cM-00FIqv-DA for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Sep 2024 00:01:54 +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 1sr4cL-000N8l-1E for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Sep 2024 00:01:53 +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 1sr4cK-000N8c-NP for pgsql-hackers@lists.postgresql.org; Thu, 19 Sep 2024 00:01:52 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sr4cH-001swV-Q9 for pgsql-hackers@postgresql.org; Thu, 19 Sep 2024 00:01:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=J4gPAeFEI5aM1HEEoklyNdb0UHBEvpkjqqLKyHtoKBM=; b=NfBw9SW4JBAkclnV5KIOmPMdak jaATdIdX3yrEZBVAMsJrANvKBheQddfQdVCMrMN2l9Zkh9synLnVnxbh/lUJYz8tDDVmYurFG+zvh I/41275IvhsmuMont0HlIw6XGQ+AvFOgsDdkUDOgvDfY5o2XfcQHtQTGiztgrHakwD+1B5qhgOYL9 O2MBp86CXwpNTGjHa+W57PtJRE5SlvHS158abGD8Cu8blPWI1LGK97u+6IbhVSdkXqEPxJM+j6Qn0 PjqLt4PWOVQoS46pZf3u6nwzXfYBi97DUOKCgMH4As/sHDnABTmQLqB8zuseCgnqZQB7PGVgbRORA 3aNNlwgQ==; Received: from 4.140.178.217.shared.user.transix.jp ([217.178.140.4] helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1sr4cE-004Pjz-4S; Thu, 19 Sep 2024 00:01:48 +0000 Date: Thu, 19 Sep 2024 09:01:34 +0900 (JST) Message-Id: <20240919.090134.1961749747398456709.ishii@postgresql.org> To: dgrowleyml@gmail.com Cc: ashutosh.bapat.oss@gmail.com, orlovmg@gmail.com, jian.universality@gmail.com, pgsql-hackers@postgresql.org Subject: Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN From: Tatsuo Ishii In-Reply-To: References: <20240917.150626.1951146285916205741.ishii@postgresql.org> <20240918.211246.1127161704188186085.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Thu, 19 Sept 2024 at 00:13, Tatsuo Ishii wrote: >> Actually there's one more executor node type that uses tuplestore: >> recursive union (used in "with recursive"). The particular node type >> uses two tuplestore and we cannot simply apply tuplestore_get_stats() >> to the node type. We need to modify RecursiveUnionState to track the >> maximum tuplestore usage. I am not sure this would be worth the >> effort. Opinion? > > Could you add the two sizes together and take the storage type from > the tuplestore with the highest storage size? I don't think this works because tuplestore_begin/tuplestore_end are called while executing the node (ExecRecursiveUnion). I think the way you are proposing only shows the stats last time when those tuplestore are created. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp