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.96) (envelope-from ) id 1w8rim-000xIu-0L for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Apr 2026 03:30:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8rik-00FGAW-0E for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Apr 2026 03:30:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w8rij-00FGAN-2O for pgsql-hackers@lists.postgresql.org; Sat, 04 Apr 2026 03:30:50 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w8rih-00000000UTf-11jf for pgsql-hackers@lists.postgresql.org; Sat, 04 Apr 2026 03:30:49 +0000 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-43d23305225so1808520f8f.2 for ; Fri, 03 Apr 2026 20:30:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775273444; cv=none; d=google.com; s=arc-20240605; b=a+eUc9dcihPRtXBPisz6fTBdXvsrtfDtsTD/Y/70/8T9+KnVKN9XvcBRTxuZOuwopI UjTbeezPkN/98Hpw0d4rWd6eypp9ZdpXw0XGJ6uk4+tUKPrsEbn2vNLBLJpZt71qPZAh KIhsMdP8e4MNC3agom7+kGJ8SBxe8Ig3JJQag97hCAzUbZiNEavtBGHhgQUX5XOqUPHn EnWfXS//67x4wxc/2ZfOZ7V4khupQaR6QhQvRbcU3FmAazenros0qpYG0I4wginC4yPb yEi0EYHX2/dMCCHjtARjtkI9APeBu7Iwj1XqAHVJNoEXxKFY2OEljsGeN9N2+ZURFrU4 93fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=q2HoNiJeI36iZpyRX74FP8GWzknZxXJSMe4Cb611Xbk=; fh=WwfprmRVYTDYW5Yw/q9UZUhQoaLrAfOA0P17pIHq090=; b=ZzeR7DxkB/geUZWQhLN0y04I8DRh3quF+TUV+uHuo3HddaFdDVGXH3YIID4nFqA/rt G28jweRJFSQLfL3eeD5/xMrDKMEJWVZUvWm/lY9Rlt878NJojsSo5MvK2W0fossHBQDD DGvBgL/lucpw/rcX9FNX4pwIk6HhANVnJW4IAkx10eDCvGCG2INfsydXeB8WHUWTUIpb eTx80GwJlZ00E72EhRadaPubkBu0HoPYN+OPKcxDGPUbBk4k4JnTBdOWQPfmnw0ipYDp TLHPZGDqbPlikkfFj8mNBNvfD0AkBvuZJ0jd6u7J+zUrZtSDxZy8bjrj+MyN5PdjEAzR T8EQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775273444; x=1775878244; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q2HoNiJeI36iZpyRX74FP8GWzknZxXJSMe4Cb611Xbk=; b=Vt48NsK/BDiqc7xcoohksafToqiIKA0zmY3uymOLpUoYQU+6fwIoljzlVvcYto7Rvv APaj+WqMrsJWvGX87h+f0RL7/LieGzMY3rSrd3aOsE7DlqyWuNnlI2UfMx1orlpBND3V 0lwKqhRaHweqwChhp/UcqwZt9pX6XhS7jt3A8o7c2YH/VHnV3qm2+FWwe7eh8JuS3WjS 8KJoshzcx2tg6We1z1Wk8FfXze/ZZgyH5cuPGdoXrMsJAjkUjsxHhz28Xe5LgGOs0irb fdLzzC6QSmmWBwRt3YDTSiDld6NCsrVEWphbCrfz1wMUpdRyhbSGjPvDHC37DUuXp35m bS/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775273444; x=1775878244; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=q2HoNiJeI36iZpyRX74FP8GWzknZxXJSMe4Cb611Xbk=; b=QyffkOrk7igM+lb0jLw48z0t98K41+a+ajRNenswZReKDxLCPq+QxNt27sIoTM/BV8 lmtw7lxHVFbUrJrdzRnhZbEu+gbNCIEw4AVC8Dq6acwgT05UhU1iFT7p7LddE69CfL4N 4h8ncc7SuHznlLOI9oXmkeNkcJ8v5+f2yiYyQcO8xf0CSQ98NU6irdUC5IiAYjKKXtJN 20N2Uuct6HfHT2ZcMKSaYevk0yGhekSRTeAH/2ZiXk9pb2C/dKIn1Y9Lp936tdJP/Gc/ SX75HWJyvNe5CkK/OL5FnFqyw8aTl93NWkUKebbgQbbaeBRuyfhVFx25IuanUoIIHItr dVsQ== X-Forwarded-Encrypted: i=1; AJvYcCW0WDN4JJ8Zk/edPPTnCnFZOnvWs9DsVsNZxVcZLG5GY054XYf0c9MmO1JvR7g4UorAGPj8uFG26YcTeGon@lists.postgresql.org X-Gm-Message-State: AOJu0YwTR8OZCH0//3M1NthGdsucTtai5ZmgeZUCIWhebAg6J3buaCYM kJWrMOYwSkt8u5ihGrvSa47T3Cj/YkYw7yyN81kzGugtl8czr4JYwb6jzRu6/ic6Luquar9IDHr CSdhUxBNOJlhZg2z4f2NEWLJgmldo64M= X-Gm-Gg: AeBDietpH3XP9Ondh4DtU3cQv27HBh0G/XE689htFNOcQQeAyIw/IqSenGOebhRY8tC lWumo4nfhewThXWGI/1mOzE+Rz94UBrJjG6mzTBeR8HrCgFfw/oEG6nVavEKsdhJZWOxDEdPZBB H5Vk3+/dBma3iytCEEOWWVCQcqvh73+0bEuGLbFoNFzzDUluipCn9HnUKZIZ7HXYGrel5taxlLo mdAWcn522Ut836xrZxWyWedidxA55Yc38GZwGe2SQ+6v5l5JonWQUkaHXx3UC+5RXYRbC4PKZkN uFhkpr8ZVeDRkAlB8jzitdPyzr7Im56iG+FR+fd0nQ2vamlefrAh4t6hUh31eilmhyzEHfvm X-Received: by 2002:a5d:64c3:0:b0:43c:f1da:488a with SMTP id ffacd0b85a97d-43d292765bcmr7479583f8f.13.1775273443613; Fri, 03 Apr 2026 20:30:43 -0700 (PDT) MIME-Version: 1.0 References: <3190647.1775103768@sss.pgh.pa.us> <59B9EFAF-84DF-40A9-847F-9CF457A798BB@gmail.com> In-Reply-To: From: David Rowley Date: Sat, 4 Apr 2026 16:30:32 +1300 X-Gm-Features: AQROBzCtDnsVj8saxPRrgfTwFMtWWDIZTRTwGymm3WtyeTPnRC90IO3E-phqwDo Message-ID: Subject: Re: Small and unlikely overflow hazard in bms_next_member() To: Chao Li Cc: Tom Lane , PostgreSQL Developers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, 4 Apr 2026 at 02:28, Chao Li wrote: > In test_bms_next2.c, you set words_to_alloc =3D 1, which disables the opt= imization in the unrolled version. If I change words_to_alloc =3D 2, then o= n my MacBook M4, the unrolled version seems to win: > ``` > chaol@ChaodeMacBook-Air test % ./test_bms_next2 > Benchmarking 100000000 iterations... > > Original: 0.61559 seconds > David's: 0.61651 seconds > Chao's version: 1.06033 seconds > Unrolled loop: 0.60561 seconds > 2800000000 > ``` Doing the same locally, here's what I get on my Zen2 machine: drowley@amd3990x:~$ gcc test_bms_next.c -O2 -o test_bms_next && ./test_bms_= next Benchmarking 100000000 iterations... Original: 1.21125 seconds David's: 1.11997 seconds Chao's version: 1.72662 seconds Unrolled loop: 1.63090 seconds 2800000000 drowley@amd3990x:~$ clang test_bms_next.c -O2 -o test_bms_next && ./test_bms_next Benchmarking 100000000 iterations... Original: 1.10780 seconds David's: 1.05968 seconds Chao's version: 1.87123 seconds Unrolled loop: 1.11002 seconds 2800000000 > I guess one-word Bitmapset are probably the most common case in practice.= So overall, I agree that your version is the best choice. Please go ahead = with it as we have already gained both a bug fix and a performance improvem= ent. If we really want to study the performance more deeply, I think that w= ould be a separate topic. Yeah, but it's better to find bottlenecks and focus there than to optimise blindly without knowing if it'll make any actual difference. It's still important to test for regressions when modifying code and try to avoid them, as it's sometimes not obvious if the code being modified is critical for performance. I also don't think we should be doing anything to optimise for multi-word sets at the expense of slowing down single-word sets. Not that it's very representative of the real world, but I added some telemetry to bitmapset.c and I see 43 multi-word sets being created and 1.45 million single-word sets created during make check, or 1 in 33785, if you prefer. diff --git a/src/backend/nodes/bitmapset.c b/src/backend/nodes/bitmapset.c index 786f343b3c9..21b5053e9a2 100644 --- a/src/backend/nodes/bitmapset.c +++ b/src/backend/nodes/bitmapset.c @@ -219,6 +219,10 @@ bms_make_singleton(int x) int wordnum, bitnum; + if (x >=3D 64) + elog(NOTICE, "multi-word set bms_make_singleton"); + else + elog(NOTICE, "single-word set bms_make_singleton"); if (x < 0) elog(ERROR, "negative bitmapset member not allowed"); wordnum =3D WORDNUM(x); @@ -811,6 +815,9 @@ bms_add_member(Bitmapset *a, int x) wordnum =3D WORDNUM(x); bitnum =3D BITNUM(x); + if (x >=3D 64 && a->nwords =3D=3D 1) + elog(NOTICE, "multi-set bms_add_member"); + /* enlarge the set if necessary */ if (wordnum >=3D a->nwords) { Not quite perfect as a set made first as a single word set that later becomes a multi-word set will be double counted. The number of operations on the sets is likely more important anyway, not the number of sets being created. The point is, multi-word sets are rare for most workloads. David