Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id B3820633ACE for ; Wed, 13 Jan 2010 18:08:28 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 80456-02 for ; Wed, 13 Jan 2010 22:08:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 10188632B2A for ; Wed, 13 Jan 2010 18:08:17 -0400 (AST) 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 o0DM8GFR005784; Wed, 13 Jan 2010 17:08:16 -0500 (EST) To: "Jorge Montero" cc: pgsql-performance@postgresql.org Subject: Re: Hashaggregate estimates In-reply-to: <4B4DEDB5.2E1C.0042.0@homedecorators.com> References: <4B4DEDB5.2E1C.0042.0@homedecorators.com> Comments: In-reply-to "Jorge Montero" message dated "Wed, 13 Jan 2010 15:58:45 -0600" Date: Wed, 13 Jan 2010 17:08:15 -0500 Message-ID: <5783.1263420495@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.459 tagged_above=-10 required=5 tests=AWL=0.140, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201001/266 X-Sequence-Number: 37146 "Jorge Montero" writes: > The killer seems to be the row aggregation. There are about 95K > different values of sku_id in the sales table, and even the best > seller items are a very small percentage of all rows, so expecting the > aggregation to consolidate the rows 50:1 like it does in one of the > explains above is a pipe dream. I've increased statistics in sku_id > into the three digits, but results are not any better Yeah, estimating the number of distinct values from a sample of the data is a hard problem :-(. > Is there any way I can coax Postgres into making a more realistic > aggregation estimate? There's no good way in 8.3. (In CVS HEAD there's a feature to manually override the ndistinct estimate for a column.) In principle you could manually update the pg_statistic.stadistinct value for the column, but the trouble with that is the next ANALYZE will overwrite it. regards, tom lane