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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
Дата
Msg-id 2374.1366296417@sss.pgh.pa.us
обсуждение исходный текст
Ответ на "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan  (dmitry potapov <potapov.dmitry@gmail.com>)
Ответы Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-performance
dmitry potapov <potapov.dmitry@gmail.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


В списке pgsql-performance по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
Следующее
От: Michael Okner
Дата:
Сообщение: Query planner ignoring constraints on partitioned tables when joining