Hello,
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)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:
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%'
)
);
http://explain.depesz.com/s/tcn
Execution time: 2037872.420 ms (almost 34 minutes!!)
If I comment out "1=2 OR", then the plan changes dramatically:http://explain.depesz.com/s/5rsW
Execution time: 617.778 ms
I know LEFT JOIN or EXISTS instead of NOT IN in this case will give better plans. What bothers me is not performance of this particular query, but the strange behavior of query planner. Is this behavior considered normal, or should I file a bug?
version: PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit
package: postgresql91-server.x86_64 9.1.9-1PGDG.rhel6
os: Scientific Linux 6.3
postgresql.conf: http://pgsql.privatepaste.com/e3e75bb789
--
