Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 01C4F19C23A2 for ; Sat, 3 Mar 2012 23:03:47 -0400 (AST) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S41jc-0008Hx-LX for pgsql-performance@postgresql.org; Sun, 04 Mar 2012 03:03:46 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id q2433UM9001858; Sat, 3 Mar 2012 22:03:30 -0500 (EST) To: Claus Stadler cc: pgsql-performance@postgresql.org Subject: Re: ...WHERE TRUE" condition in union results in bad query pla In-reply-to: <4F529E85.8010506@informatik.uni-leipzig.de> References: <4F529E85.8010506@informatik.uni-leipzig.de> Comments: In-reply-to Claus Stadler message dated "Sat, 03 Mar 2012 23:43:17 +0100" Date: Sat, 03 Mar 2012 22:03:29 -0500 Message-ID: <1857.1330830209@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201203/45 X-Sequence-Number: 46495 Claus Stadler 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... regards, tom lane