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
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 |