Date: Mon, 16 Sep 2024 21:13:17 +0900 (JST)
Message-Id: <20240916.211317.396133556663707937.ishii@postgresql.org>
To: ashutosh.bapat.oss@gmail.com
Cc: dgrowleyml@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 <ishii@postgresql.org>
In-Reply-To: 
 <CAExHW5uwOz8aySLQHb1VRmfccf0-JMydvcS2A9_O-j=Kduqkyw@mail.gmail.com>
References: 
 <CAExHW5vjV1=oLsX8Hw8+M3Vf2Fuurq8HPUa4Ms8mC5H5DZPjcA@mail.gmail.com>
	<20240914.171201.2241093933296787263.ishii@postgresql.org>
	<CAExHW5uwOz8aySLQHb1VRmfccf0-JMydvcS2A9_O-j=Kduqkyw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20240916.211317.396133556663707937.ishii%40postgresql.org>
Precedence: bulk

Hi Ashutosh,

Thank you for the review.

> Thanks. This will do. Is there a way to force the larger partition to
> be computed first? That way we definitely know that the last
> computation was done when all the tuples in the tuplestore were in
> memory.

Not sure if there's any way to force it in the SQL standard.  However
in term of implementation, PostgreSQL sorts the function
(generate_series) scan result using a sort key "a.n < 3", which
results in rows being >= 2 first (as false == 0), then rows being < 3
(as true == 1). So unless PostgreSQL changes the way to sort boolean
data type, I think the result should be stable.

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp