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 1sm5ha-003Au7-GX for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2024 06:10:42 +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 1sm5hX-0046a3-Nh for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2024 06:10:40 +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 1sm5hX-0046YV-B0 for pgsql-hackers@lists.postgresql.org; Thu, 05 Sep 2024 06:10:39 +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 1sm5hU-000EFm-4T for pgsql-hackers@postgresql.org; Thu, 05 Sep 2024 06:10:38 +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=PE2uZ24CJctfv5FYuk+Xh6SRVNjMEXLkRgRFxv9mIJU=; b=P5ZFOYCQ3BjS5xjCUB1MdIEK9Z D2OqQOB1zc9RolHatDmKP23uUVPxrG+1i29BHyIGyyT5O/Cn8kY0emwaEHkhVWP8lKDjFzza52N4M Cf/U86N/QtX2/aY4eVSK/1s8j883EyYSsctN9TUDGqOfmUqPI74ZHRPE4RPv6Cn9DFIFAwbgjq3Lc vbyzhKAlAE1shnE7ptFa2HKydSFfhI8554H+ASmImrP/+phfeZp/P91RbNbBsOqlR+xMkUX1o8ifd xGIkO+BFQhzjpn5Qvxi8FopAZ6IE2A4i+ec2jpy3T3/TkEqWUKgk0pMWI97+qAGQrASo3Zf4uML8Q 3n5FUeZA==; Received: from 185.184.178.217.shared.user.transix.jp ([217.178.184.185] 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 1sm5hP-000Ypv-AD; Thu, 05 Sep 2024 06:10:34 +0000 Date: Thu, 05 Sep 2024 15:10:24 +0900 (JST) Message-Id: <20240905.151024.1730395991018096027.ishii@postgresql.org> To: jian.universality@gmail.com Cc: dgrowleyml@gmail.com, ashutosh.bapat.oss@gmail.com, pgsql-hackers@postgresql.org Subject: Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN From: Tatsuo Ishii In-Reply-To: References: <20240709.154409.1091516017393224028.ishii@postgresql.org> <20240710.183610.1211398886785110571.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 Hi, > hi. I can roughly understand it. > > I have one minor issue with the comment. > > typedef struct RecursiveUnionState > { > PlanState ps; /* its first field is NodeTag */ > bool recursing; > bool intermediate_empty; > Tuplestorestate *working_table; > Tuplestorestate *intermediate_table; > int64 storageSize; /* max storage size Tuplestore */ > char *storageType; /* the storage type above */ > .... > } > > "/* the storage type above */" > is kind of ambiguous, since there is more than one Tuplestorestate. > > i think it roughly means: the storage type of working_table > while the max storage of working_table. > > > > typedef struct WindowAggState > { > ScanState ss; /* its first field is NodeTag */ > > /* these fields are filled in by ExecInitExpr: */ > List *funcs; /* all WindowFunc nodes in targetlist */ > int numfuncs; /* total number of window functions */ > int numaggs; /* number that are plain aggregates */ > > WindowStatePerFunc perfunc; /* per-window-function information */ > WindowStatePerAgg peragg; /* per-plain-aggregate information */ > ExprState *partEqfunction; /* equality funcs for partition columns */ > ExprState *ordEqfunction; /* equality funcs for ordering columns */ > Tuplestorestate *buffer; /* stores rows of current partition */ > int64 storageSize; /* max storage size in buffer */ > char *storageType; /* the storage type above */ > } > > " /* the storage type above */" > I think it roughly means: > " the storage type of WindowAggState->buffer while the max storage of > WindowAggState->buffer". Thank you for looking into my patch. Unfortunately I need to work on other issue before adjusting the comments because the fields might go away if I change the tuplestore infrastructure per David's suggestion: https://www.postgresql.org/message-id/CAApHDvoY8cibGcicLV0fNh%3D9JVx9PANcWvhkdjBnDCc9Quqytg%40mail.gmail.com After this I will rebase the patches. This commit requires changes. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=908a968612f9ed61911d8ca0a185b262b82f1269 Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp