Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dmitry potapov <potapov(dot)dmitry(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
Date: 2013-04-18 14:46:57
Message-ID: 2374.1366296417@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

dmitry potapov <potapov(dot)dmitry(at)gmail(dot)com> writes:
> I recently stumbled upon on what could be a planner bug or a corner case.
> If "<false condition> OR ..." is added to WHERE clause of SELECT query,
> then the planner chooses a very inefficient plan. Consider a query:

> SELECT count(k0.id)
> FROM k0
> WHERE 1 = 2
> OR k0.id IN (
> SELECT k1.k0_id
> FROM k1
> WHERE k1.k1k2_id IN (
> SELECT k2.k1k2_id
> FROM k2
> WHERE k2.t = 2
> AND (coalesce(k2.z, '')) LIKE '%12%'
> )
> );

Perhaps you should fix your application to not generate such incredibly
silly SQL. Figuring out that 1=2 is constant false and throwing it away
costs the server easily a thousand times as many instructions as it
would take for the client to not emit that in the first place.

The reason you don't get a nice semijoin plan when you do that is that
conversion of IN clauses to semijoins happens before
constant-subexpression simplification. So the planner hasn't yet
figured out that the OR is useless when it would need to know that to
produce a good plan. (And no, we can't just flip the order of those two
steps. Doing two rounds of const-simplification wouldn't be a good
answer either, because it would penalize well-written queries to benefit
badly-written ones.)

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message ktm@rice.edu 2013-04-18 20:54:08 Re: High CPU usage buy low I/O wait
Previous Message Richard Huxton 2013-04-18 14:43:20 Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan