Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 12E659FB402 for ; Tue, 30 Jan 2007 10:54:52 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 88692-01 for ; Tue, 30 Jan 2007 10:54:44 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from globalrelay.com (mail1.globalrelay.com [204.92.49.200]) by postgresql.org (Postfix) with ESMTP id B6E4C9FB3F0 for ; Tue, 30 Jan 2007 10:54:44 -0400 (AST) X-Virus-Scanned: Scanned by GRC-AntiVirus Gateway X-GR-Acctd: YES Received: from [71.215.208.64] (HELO DaveEMachine) by globalrelay.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 125287083; Tue, 30 Jan 2007 06:54:34 -0800 From: "Dave Dutcher" To: "'Tom Lane'" Cc: Subject: Re: Bad Row Count Estimate on View with 8.2 Date: Tue, 30 Jan 2007 08:54:33 -0600 Message-ID: <00d501c7447e$8e227760$8300a8c0@tridecap.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6822 Importance: Normal Thread-Index: AcdDDPhumOj6V9x7TsumA3TOhsHKGwBb27lw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-reply-to: <17556.1170010078@sss.pgh.pa.us> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/426 X-Sequence-Number: 23027 > From: pgsql-performance-owner@postgresql.org=20 > [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Tom Lane >=20 > I took another look and think I found the problem: 8.2's new code for > flattening UNION ALL subqueries into "append relations" is failing to > initialize all the fields of the appendrel, which confuses > estimate_num_groups (and perhaps other places). I think this will fix > it for you. >=20 I gave this a try on our test machine yesterday and it worked. The = planner was estimating that the group by on the union would return about 300 = rows which is very similar to what 8.1.2 thought. Actually it returned about 3000 rows, but still it is a good enough estimate to pick a plan which = takes 100ms instead of a plan which takes 100 seconds. Thanks, Dave