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 1l1QoK-0001mf-Rp for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jan 2021 09:26:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l1QoI-0004q8-OK for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jan 2021 09:26:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1QoI-0004pz-Hi for pgsql-hackers@lists.postgresql.org; Mon, 18 Jan 2021 09:26:54 +0000 Received: from [64.147.123.30] (helo=wforward1-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1QoB-0005YR-67 for pgsql-hackers@postgresql.org; Mon, 18 Jan 2021 09:26:53 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id 6EF0D1639; Mon, 18 Jan 2021 04:26:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 18 Jan 2021 04:26:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=/9z+fPYtgj5t7tS/UHtmlW46aDPGYMfgDTfhXAUWi Ak=; b=BwhE5gekkfNZuLMPiw551ZBmQbVE99zJ3JdmXQdFUyM1BdOH/WmUs6HOC YymdA5KzHH53LPKHZVFYTYj3ad/9oNbX7GJTaWisf4q4D7cXKAkw+7bhBtKAKAP2 lOCotCug1SUK21NNfWZonLt5OxtnX1Fi7lx2xPbIkVgFXeVJ7os56dk+1ve8gVwJ WfJ5k7llCoLtF6u9bztrorp/vwFC9Emyo0HCsbakBOirTaZAkTkHgrWucV8xMm7S nmyBTw0jHcogxdo/dlxr9l3RuH49a5t3cYxlbovz976Kb240FhjAkT81biqICU1P dyw4aOPec4RhVsfwGCXiEpv7ZkxMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdekgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefheenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepffdvueeftdfggfevffdv heejkeejkeehvddvueehgefhffelvdfgffffffefjedunecukfhppeekjedrudejjedrje dvrddugedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepphgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: from april.pezone.net (p57b1488e.dip0.t-ipconnect.de [87.177.72.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E536108006A; Mon, 18 Jan 2021 04:26:33 -0500 (EST) Subject: Re: popcount To: David Fetter References: <20201230105535.GJ13234@fetter.org> <5ea2932e-50f5-4a74-9550-5e3291b6652b@manitou-mail.org> <20201230164108.GK13234@fetter.org> <20210111161354.GA8721@fetter.org> Cc: Daniel Verite , PostgreSQL Development , Vik Fearing From: Peter Eisentraut Organization: EnterpriseDB Message-ID: Date: Mon, 18 Jan 2021 10:24:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20210111161354.GA8721@fetter.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.147.123.30 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-01-11 17:13, David Fetter wrote: > On Mon, Jan 11, 2021 at 03:50:54PM +0100, Peter Eisentraut wrote: >> On 2020-12-30 17:41, David Fetter wrote: >>>> The input may have more than 2 billion bits set to 1. The biggest possible >>>> result should be 8 billion for bytea (1 GB with all bits set to 1). >>>> So shouldn't this function return an int8? >>> It does now, and thanks for looking at this. >> >> The documentation still reflects the previous int4 return type (in two >> different spellings, too). > > Thanks for looking this over! > > Please find attached the next version with corrected documentation. The documentation entries should be placed in alphabetical order in their respective tables. For the bytea function, maybe choose a simpler example that a reader can compute in their head. Also for the test cases. In varbit.c: The comment says + * Returns the number of bits set in a bit array. but it should be "bit string". + int8 popcount; should be int64. Also, pg_popcount() returns uint64, not int64. Perhaps overflow is not possible here, but perhaps a small comment about why or an assertion could be appropriate. + p = VARBITS(arg1); Why not assign that in the declaration block as well? This comment: + /* + * ceil(VARBITLEN(ARG1)/BITS_PER_BYTE) + * done to minimize branches and instructions. + */ I don't know what that is supposed to mean or why that kind of tuning would be necessary for a user-callable function. + popcount = pg_popcount((const char *)p, len); The "const" is probably not necessary. byteapopcount() looks better, but also needs int8 -> int64.