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 1rXewW-00BsdW-Kb for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Feb 2024 10:14:13 +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 1rXewV-009jAS-Qy for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Feb 2024 10:14:11 +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 1rXevq-009gLs-MG for pgsql-hackers@lists.postgresql.org; Wed, 07 Feb 2024 10:13:30 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rXevn-005WCY-Qt for pgsql-hackers@lists.postgresql.org; Wed, 07 Feb 2024 10:13:29 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E2FF15C00C2; Wed, 7 Feb 2024 05:13:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 07 Feb 2024 05:13:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707300806; x= 1707387206; bh=ShKei0bC1O1EzsOR2cV/N3HMTOH/oyRbcwJS/G6AG4s=; b=u AATlinWifhNgOK/F+C6tRZ5kE2eQ0B94afkl4djbtpnDp7aFzsKBdB+GZ64HFQQs /SJZcr7WmHEhnKtWCqXPaOJt3z5ZAYSAa4JHDoL3xnT0dGvvzNs9p71G2YVhKdGu 4BjlAo2N6U+wRHx+lY1e7Ou7L832cmEW0Uwg7gAKGGt5Dvnn0D8IY8VcatrRlxJr 8Ai1OSkObnsDEagnIT56YlM/11XqE2rQWxCOuiY2P8JZRq398xE5Sp6DeN+8rTiS nrPM028zOZvbr0weUxv0hT4AkWRnvX4z3QEmV8HRi8xpYiFqsTYfzdhjFxDuytwb OyacTnXmYeeOJ3kSwiWjQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtddvgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeeufefftefhffetieegleejuddtkefhkeejveejteelleei vedvuedvheduvdfffeenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgpdhmvg hrrhhirghmqdifvggsshhtvghrrdgtohhmpdgvnhhtvghrphhrihhsvggusgdrtghomhen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhh gvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Feb 2024 05:13:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1707300804; bh=wLTyEtrLYmfITL4/CQIPF93zoL3fcKdPlgyYcAJBRG4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=GPFGuinARw6+cGMUmZkiDYVj/TmMa2FAEcB/cHSb+1xeLoi/7C8VT2U8+aA55kpP7 5xX0PNIhiS/WeSltDBEvjY5D+V/3PY08hr2ITrgsN6B4JS2Q/meTtu655nyH+ssRXj Sno1aVKbHgo89hHZYZCmwJojQHZ15hPvueaTu+c0D9z3hMroWGnh469qzrFdLCh6zK TYq/vVWmuPqw7m6MLU5Q8+Fjbd3POOMqicwrMFZLcCRE6lcN6jyDryqmqXnFJOk1K3 b6buvJEnfCjPh5IWWIARkGBporh8lnrfwQBnRGwAmikpcVd5V0Xm+vL+dYV1fU56f6 35TMS9WJtZmrg== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 70F84BA3; Wed, 7 Feb 2024 11:13:24 +0100 (CET) Date: Wed, 7 Feb 2024 11:13:24 +0100 From: Alvaro Herrera To: Ashutosh Bapat Cc: Justin Pryzby , pgsql-hackers@lists.postgresql.org, David Rowley Subject: Re: pgsql: Add EXPLAIN (MEMORY) to report planner memory consumption Message-ID: <202402071013.x6psffds5qpu@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Many thanks, Justin, for the post-commit review. On 2024-Feb-06, Ashutosh Bapat wrote: > On Tue, Feb 6, 2024 at 3:51 AM Justin Pryzby wrote: > > > > Up to now, the explain " " (two space) format is not mixed with "=". > > > > And, other places which show "Memory" do not use "=". David will > > remember prior discussions. > > https://www.postgresql.org/message-id/20200402054120.GC14618@telsasoft.com > > https://www.postgresql.org/message-id/20200407042521.GH2228@telsasoft.com > > > > "Memory: used=%lld bytes allocated=%lld bytes", > > vs > > "Buckets: %d (originally %d) Batches: %d (originally %d) Memory Usage: %ldkB\n", > > I have used = to be consistent with Buffers usage in the same Planning section. > > Are you suggesting that > "Memory: used=%lld bytes allocated=%lld bytes", > should be used instead of > "Memory: used=%lld bytes allocated=%lld bytes", > Please notice the single vs double space. I think using a single space here would be confusing. It's not a problem for show_wal_usage because that one doesn't print units. I don't know it was you (Ashutosh) or I that put the double space, but I considered the matter and determined that two were better. In the new line we have two different separators (: and =) because there are two levels of info being presented; in the show_hash_info one we have only one type of separator. I'm not saying this is final and definite. I'm just saying I did consider this whole format issue and what you see is the conclusion I reached. It may or may not be what Ashutosh submitted -- I don't remember. As committer, I almost always tweak submitted patches, and I won't apologize for that. Further patches to correct my mistakes and bad decisions always welcome. > > (Also, I first thought that "peek" should be "peak", but eventually I > > realized that's it's as intended.) > > Don't understand the context. But probably it doesn't matter. Source code always matters. Why would people spend so much time fixing typos otherwise? src/backend/commands/explain.c: static bool peek_buffer_usage(ExplainState *es, const BufferUsage *usage); We don't want to know what the "peak" buffer usage is, but we want to "peek" whether buffer usage would print anything. I did have to spent a minute thinking what the correct spelling was, here (but my English is almost exclusively read/written, not spoken. Condolencies if you've had to suffer my spoken English at some conference or whatever). I didn't look at the dictionary back then, but now I do: https://www.merriam-webster.com/dictionary/peek As Justin says, it's the right word. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was amazing when I first started using it at 7.2, and I'm continually astounded by learning new features and techniques made available by the continuing work of the development team." Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php