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 1wuwL5-000zyq-30 for pgsql-bugs@arkaria.postgresql.org; Fri, 14 Aug 2026 18:09:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wuwL3-001xyy-1u for pgsql-bugs@arkaria.postgresql.org; Fri, 14 Aug 2026 18:09:06 +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 1wuvtz-001uOU-1H for pgsql-bugs@lists.postgresql.org; Fri, 14 Aug 2026 17:41:08 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wuvtx-00000000kIL-33ZV for pgsql-bugs@lists.postgresql.org; Fri, 14 Aug 2026 17:41:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=L3L2nIea3zKfpwfdOMaaQakjq54VVNiwPHC6gkYBqiE=; b=VXZWyzHFaifBwAezOa7PNlyGvk D3WfjOF6uKfNjvX2RNON4WLUg6trhic4CDVaUK4g4BQbxYG/zJSIflA2hJ7/ReJ2IOrI6SlMqa7hQ YO5r2/JMEHr7Hqr4nCAIIaX0tG3FHaMgnoG2QKs+H+oafus5LnNT8FAEpGXreIcvVzkEt58Ii/IJC y31RHGu6rm/YOYm+/8ZNIKWKENRYQbLRWwRWVAsuUMTbBSf88EReATQO8T3LwymKxmlME7/kK9Kkr WEWYH/f5pwMw5qOpCj1rnFXgUKzAu3HApqQGw7p56qKif3CZyQeNmb+FsYMUfPtzF0C3MW+HOWu0r WcEig3mw==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wuvtw-001tPi-2I for pgsql-bugs@lists.postgresql.org; Fri, 14 Aug 2026 17:41:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1wuvtu-00000005NjH-43zA for pgsql-bugs@lists.postgresql.org; Fri, 14 Aug 2026 17:41:02 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19619: WHERE scale(n) = 1 pushed past GROUP BY / window PARTITION BY, wrong COUNT To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: malis@pgrust.com Reply-To: malis@pgrust.com, pgsql-bugs@lists.postgresql.org Date: Fri, 14 Aug 2026 17:41:02 +0000 Message-ID: <19619-fc646db1c6b2dc90@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19619 Logged by: Michael Malis Email address: malis@pgrust.com PostgreSQL version: 18.6 Operating system: MacOS Description: =20 The planner pushes WHERE scale(n) =3D 1 (and the equivalent HAVING) past GROUP BY n and window PARTITION BY n. numeric values 1.0, 1.00 and 1.000 compare equal, so they form one group / one window partition, but scale() distinguishes them. Pushing the filter into the scan drops two of the three rows before the aggregate or window runs, so COUNT(*) is 1 instead of 3. Wrong answers, not a crash. Version: PostgreSQL 18.6 on aarch64-apple-darwin24.5.0, compiled by Apple clang version 17.0.0 (clang-1700.0.13.5), 64-bit Configure: --enable-cassert --enable-debug Reproducer ---------- CREATE TABLE nums (n numeric); INSERT INTO nums VALUES (1.0), (1.00), (1.000); ANALYZE nums; -- Wrong: filter is pushed below the window SELECT n, c FROM ( SELECT n, COUNT(*) OVER (PARTITION BY n) AS c FROM nums ) s WHERE scale(n) =3D 1 ORDER BY 1; -- Correct: OFFSET 0 blocks pushdown; filter stays above the window SELECT n, c FROM ( SELECT n, COUNT(*) OVER (PARTITION BY n) AS c FROM nums OFFSET 0 ) s WHERE scale(n) =3D 1 ORDER BY 1; -- Same bug for GROUP BY SELECT c FROM ( SELECT n, COUNT(*)::int AS c FROM nums GROUP BY n ) s WHERE scale(n) =3D 1; SELECT c FROM ( SELECT n, COUNT(*)::int AS c FROM nums GROUP BY n OFFSET 0 ) s WHERE scale(n) =3D 1; -- Same bug for HAVING (moved to WHERE) SELECT n, COUNT(*)::int AS c FROM nums GROUP BY n HAVING scale(n) =3D 1;