Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWG5t-00014N-Oa for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Sep 2022 11:53:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oWG5s-0003Rj-HP for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Sep 2022 11:53:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWG5s-0003Ra-7G for pgsql-hackers@lists.postgresql.org; Thu, 08 Sep 2022 11:53:16 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWG5p-0003b3-JF for pgsql-hackers@postgresql.org; Thu, 08 Sep 2022 11:53:15 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 110EA5C007E for ; Thu, 8 Sep 2022 07:53:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 08 Sep 2022 07:53:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1662637992; x=1662724392; bh=13F2sx+3nPSbbxcOD/pLWNs1N6fY 1U7zjWEiGyCRj1U=; b=dUi5we2nChrqSITEIS52qP/fjFPSHRPqPQnKpGHb4ZwY iMBn/zXuRVDdLmr9RBtQ/nknKMH/e5DGRNxdVqNZpTZhqg/wvGAw3oT362hC+MVr GkM7djFcl37rNy8lzGse21iV63MTRPglULZE6yG5HBItd+Qauz/s1f6PZcWleYhj ZM4OfUvO5QrG8GXlU7Myq+oaJ7+70kXaJkwVvHa69ctfSaz0iL8P2yB2TkBBDzPF y/l0MHBtjgynhg1lITVh1RJums8rFnfMpaVPQy8I0/Gf/TU78TxC7xccAn5b5y2z GbrTuXTriS/pq4njdWbITHTRvObp8BzkFK33Gb5Wzg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedtvddggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfhuffvtgfgsehtjeertd dtfeejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgv ihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtth gvrhhnpeeijeeuveeghfeiteettdegtdevhfdvleduleevveegleevtdelueehteevffdt ueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvg htvghrrdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 8 Sep 2022 07:53:11 -0400 (EDT) Message-ID: <36ee692b-232f-0484-ce94-dc39d82021ad@enterprisedb.com> Date: Thu, 8 Sep 2022 13:53:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US From: Peter Eisentraut Subject: pg_walinspect float4/float8 confusion To: pgsql-hackers Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The pg_walinspect function pg_get_wal_stats() has output arguments declared as float4 (count_percentage, record_size_percentage, etc.), but the internal computations are all done in type double. Is there a reason why this is then converted to float4 for output? It probably doesn't matter in practice, but it seems unnecessarily confusing. Or at least add a comment so it doesn't look like an accident. Also compare with pgstattuple, which uses float8 in its SQL interface for similar data.