Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TMmZ6-0000ka-7G for pgsql-performance@postgresql.org; Fri, 12 Oct 2012 21:14:40 +0000 Received: from [2001:1528:137::f1] (helo=mail.gransy.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TMmZ2-0003WH-Ut for pgsql-performance@postgresql.org; Fri, 12 Oct 2012 21:14:39 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id EE464508A94 for ; Fri, 12 Oct 2012 23:14:35 +0200 (CEST) Received: from mail.gransy.com ([82.208.44.189]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id bADrTvJwXexk for ; Fri, 12 Oct 2012 23:14:35 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id D5E50508A97; Fri, 12 Oct 2012 23:14:35 +0200 (CEST) Received: from [192.168.1.237] (ip-78-45-133-255.net.upcbroadband.cz [78.45.133.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id A5587508A94 for ; Fri, 12 Oct 2012 23:14:35 +0200 (CEST) Message-ID: <5078883B.5000509@fuzzy.cz> Date: Fri, 12 Oct 2012 23:14:35 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: hash aggregation References: <118871349885342@web16f.yandex.ru> <323831349928808@web5g.yandex.ru> <50764D55.2060401@ringerc.id.au> <53981349968513@web6f.yandex.ru> <246351350014151@web25e.yandex.ru> <270381350015278@web27h.yandex.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:1528:137::f1 (failed) X-Pg-Spam-Score: -1.1 (-) X-Archive-Number: 201210/166 X-Sequence-Number: 48125 On 12.10.2012 09:10, Sergey Konoplev wrote: > What I can not understand is why the seq scan's estimated cost is > better the index scan's one. It depends on the number of pages in > index/relation. May be the index is heavily bloated? The IOS cost depends on other things too. The index can't be read simply as a sequence of pages, the scan needs to jump around the tree to read the tuples in the right order. With the index size being close to the size of the table, the cost of these operations may easily outweight the benefits. And I suspect this is the case here, because the table has only 3 columns (INT and two text ones), and each row has some overhead (header), that may further decrease the difference between index and table size. Nevertheless, the cost estimate here is wrong - either it's estimating something wrong, or maybe everything is in the case and the planner does not know about that. Tomas