Re: ...WHERE TRUE" condition in union results in bad query pla - Mailing list pgsql-performance

From Robert Haas
Subject Re: ...WHERE TRUE" condition in union results in bad query pla
Date
Msg-id CA+TgmoY0rAmQ1W4WsixQajmFpKBAV4i9m4rnN3F2R=2qR+R2zw@mail.gmail.com
Whole thread Raw
In response to Re: ...WHERE TRUE" condition in union results in bad query pla  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ...WHERE TRUE" condition in union results in bad query pla
List pgsql-performance
On Sat, Mar 3, 2012 at 10:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Claus Stadler <cstadler@informatik.uni-leipzig.de> writes:
>> Query optimizer glitch: "...WHERE TRUE" condition in union results in
>> bad query plan ...
>
> Yeah, this is because a nonempty WHERE clause defeats simplifying the
> UNION ALL into a simple "append relation" (cf is_safe_append_member()).
> The planner will eventually figure out that WHERE TRUE is a no-op,
> but that doesn't happen till later (and there are good reasons to do
> things in that order).
>
> Sooner or later I'd like to relax the restriction that appendrel members
> can't have extra WHERE clauses, but don't hold your breath waiting...

Does this comment need updating?

 * Note: the data structure assumes that append-rel members are single
 * baserels.  This is OK for inheritance, but it prevents us from pulling
 * up a UNION ALL member subquery if it contains a join.  While that could
 * be fixed with a more complex data structure, at present there's not much
 * point because no improvement in the plan could result.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-performance by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Performance of SQL Function versus View
Next
From: Ofer Israeli
Date:
Subject: Re: TCP Overhead on Local Loopback