Re: popcount

From: David Fetter <david(at)fetter(dot)org>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
Subject: Re: popcount
Date: 2020-12-30 16:41:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Dec 30, 2020 at 05:27:04PM +0100, Daniel Verite wrote:
> David Fetter wrote:
> +Datum
> +byteapopcount(PG_FUNCTION_ARGS)
> +{
> + bytea *t1 = PG_GETARG_BYTEA_PP(0);
> + int len, result;
> +
> + len = VARSIZE_ANY_EXHDR(t1);
> + result = pg_popcount(VARDATA_ANY(t1), len);
> +
> + PG_RETURN_INT32(result);
> +}
> 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.

> There is a pre-existing function in core: bit_length(bytea) returning int4,
> but it errors out for large values (in fact it's a SQL function that returns
> octet_length($1)*8).
> For the varbit case, it doesn't seem like it can hold so many bits, although
> I don't see the limit documented in

Out of an abundance of caution, I changed that one, too.

I'd noticed earlier that ceil() doesn't need to be quite as wasteful
as the way I had it earlier, and fixed that with help from Andrew

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres:

Attachment Content-Type Size
v2-0001-popcount.patch text/x-diff 6.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Kondratov 2020-12-30 17:41:27 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Previous Message Daniel Verite 2020-12-30 16:27:04 Re: popcount