Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 5F4996502EA
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 20 Aug 2008 15:38:09 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 20465-01-9
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 20 Aug 2008 15:37:57 -0300 (ADT)
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 postgresql.org (Postfix) with ESMTP id 93360650319
	for <pgsql-performance@postgresql.org>;
	Wed, 20 Aug 2008 15:28:27 -0300 (ADT)
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 m7KISIpe003233;
	Wed, 20 Aug 2008 14:28:19 -0400 (EDT)
To: "Scott Carey" <scott@richrelevance.com>
cc: "Moritz Onken" <onken@houseofdesign.de>, pgsql-performance@postgresql.org
Subject: Re: Slow query with a lot of data 
In-reply-to: <a1ec7d000808201106j4e901d42q3a296ca1d84c2f9c@mail.gmail.com> 
References: <90AA1B69-4E9C-4710-9D58-F65620DDA022@houseofdesign.de>
	<8EF0BB61-D8FE-47E8-97DD-1009F7EB5431@houseofdesign.de>
	<alpine.DEB.1.10.0808181550110.4454@aragorn.flymine.org>
	<0BFF9855-F1FA-4A83-B8B2-622D7CE69F77@houseofdesign.de>
	<alpine.DEB.1.10.0808181657350.4454@aragorn.flymine.org>
	<3663375B-7AC0-43F6-B6EC-D3EE572F3D34@houseofdesign.de>
	<alpine.DEB.1.10.0808191202450.4454@aragorn.flymine.org>
	<24E3FBFF-E0B8-435E-ACE1-652E93FE2213@houseofdesign.de>
	<alpine.DEB.1.10.0808191311540.4454@aragorn.flymine.org>
	<380CD097-4A33-4134-8C13-B9BF34EC6C63@houseofdesign.de>
	<a1ec7d000808201106j4e901d42q3a296ca1d84c2f9c@mail.gmail.com>
Comments: In-reply-to "Scott Carey" <scott@richrelevance.com>
	message dated "Wed, 20 Aug 2008 11:06:06 -0700"
Date: Wed, 20 Aug 2008 14:28:18 -0400
Message-ID: <3232.1219256898@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200808/231
X-Sequence-Number: 31112

"Scott Carey" <scott@richrelevance.com> writes:
> The planner actually thinks there will only be 28704 rows returned of width
> 12.  But it chooses to sort 53 million rows before aggregating.  Thats
> either a bug or there's something else wrong here.   That is the wrong way
> to aggregate those results no matter how much work_mem you have unless I'm
> completely missing something...

That does look weird.  What are the datatypes of the columns being
grouped by?  Maybe they're not hashable?

Another forcing function that prevents use of HashAgg is DISTINCT
aggregates, but you don't seem to have any in this query...

			regards, tom lane