agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: Matheus Alcantara <matheusssilv97@gmail.com>
To: 2320415112@qq.com
To: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19572: Redundant predicate changes JIT decision and causes an 18x performance difference
Date: Wed, 29 Jul 2026 14:44:45 -0300
Message-ID: <DKB8Q0DL1Y1C.177HDXZVZ0G6U@gmail.com> (raw)
In-Reply-To: <19572-f770e89412629023@postgresql.org>
References: <19572-f770e89412629023@postgresql.org>
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:
>
> ## Description
>
> This issue concerns a predicate that already applies to one side of an inner
> join and is redundantly copied into the join condition. The transformation
> 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 whether
> 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 cardinality
> 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
view thread (3+ messages) latest in thread
Message-ID: <DKB8Q0DL1Y1C.177HDXZVZ0G6U@gmail.com>
Permalink: ../DKB8Q0DL1Y1C.177HDXZVZ0G6U@gmail.com/
Also on: postgresql.org/message-id/DKB8Q0DL1Y1C.177HDXZVZ0G6U@gmail.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: matheusssilv97@gmail.com, 2320415112@qq.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19572: Redundant predicate changes JIT decision and causes an 18x performance difference
In-Reply-To: <DKB8Q0DL1Y1C.177HDXZVZ0G6U@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox