Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 29 Jul 2026 14:44:45 -0300
Message-Id: <DKB8Q0DL1Y1C.177HDXZVZ0G6U@gmail.com>
Subject: Re: BUG #19572: Redundant predicate changes JIT decision and causes
 an 18x performance difference
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: <2320415112@qq.com>, <pgsql-bugs@lists.postgresql.org>
References: <19572-f770e89412629023@postgresql.org>
In-Reply-To: <19572-f770e89412629023@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/DKB8Q0DL1Y1C.177HDXZVZ0G6U%40gmail.com>
Precedence: bulk

On Wed Jul 22, 2026 at 4:34 AM -03, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      19572
> Logged by:          cl hl
> Email address:      2320415112@qq.com
> PostgreSQL version: 17.10
> Operating system:   Linux LAPTOP-2SQAVLB0 6.6.87.2-microsoft-standard-
> Description:       =20
>
> ## Description
>
> This issue concerns a predicate that already applies to one side of an in=
ner
> join and is redundantly copied into the join condition. The transformatio=
n
> is semantics-preserving. PostgreSQL retains both copies and treats their
> selectivities as independent, even though they are identical. The
> underestimated row count lowers the total plan cost enough to change whet=
her
> expensive JIT inlining and optimization are enabled.
>
> ### Expected Behaviour
>
> PostgreSQL should recognize identical predicates or account for their
> complete correlation. Adding a redundant copy should not change cardinali=
ty
> estimates, cross a JIT threshold, or produce a large execution-time
> difference between equivalent queries.
>

AFAICT the planner treats each AND clause as an independent condition
and multiplies their selectivities together. So in the duplicated case
it estimates that the Seq Scan on redundant_join_fact returns fewer rows
because there are "more" filters, even though the two are identical.
Note the actual row counts are the same in both plans, only the estimate
changes, so the results are correct. This is a cardinality-estimation
that happens to cross the JIT cost threshold. So I think that this is an
expected behavior rather than a bug, though I may be wrong.

But I'm wondering whether the planner should detect duplicated quals and
drop the redundant qual, or more generally recognize when one qual
implies another (if qual1 is true, qual2 is always true) and remove
qual2. We already have predicate_implied_by() in predtest.c, but IIUC
it's currently only used for partial indexes, partition pruning, and
constraint exclusion, but I'm not sure if it can be used for such case.

I'm not sure it's worth doing for the general case given the possible
added planning time, but exact duplicate detection might be cheap enough
to be worthwhile, but also I'm not sure if it's a common pattern to make
it worh implementing it. Any thoughts?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com