Re: ...WHERE TRUE" condition in union results in bad query pla
От | Robert Haas |
---|---|
Тема | Re: ...WHERE TRUE" condition in union results in bad query pla |
Дата | |
Msg-id | CA+TgmoY0rAmQ1W4WsixQajmFpKBAV4i9m4rnN3F2R=2qR+R2zw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ...WHERE TRUE" condition in union results in bad query pla (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ...WHERE TRUE" condition in union results in bad query pla
|
Список | 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 по дате отправления: