Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XPGZd-0007Uz-Cq for pgsql-performance@arkaria.postgresql.org; Wed, 03 Sep 2014 19:50:33 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XPGZc-0005HL-Qd for pgsql-performance@arkaria.postgresql.org; Wed, 03 Sep 2014 19:50:32 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XPGZb-0005EQ-2E for pgsql-performance@postgresql.org; Wed, 03 Sep 2014 19:50:31 +0000 Received: from sam.nabble.com ([216.139.236.26]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XPGZY-0001D9-17 for pgsql-performance@postgresql.org; Wed, 03 Sep 2014 19:50:29 +0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XPGZW-0000vD-Qd for pgsql-performance@postgresql.org; Wed, 03 Sep 2014 12:50:26 -0700 Date: Wed, 3 Sep 2014 12:50:26 -0700 (PDT) From: gmb To: pgsql-performance@postgresql.org Message-ID: <1409773826818-5817622.post@n5.nabble.com> In-Reply-To: <53FF9585.2020503@agliodbs.com> References: <1409215840535-5816702.post@n5.nabble.com> <53FF9585.2020503@agliodbs.com> Subject: Re: Performance issue: index not used on GROUP BY... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: 0.8 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Thanks for the feedback, everybody. I spent a couple of days trying to optimise this; As mentioned , the increased memory is not an option for me, as this query is part of a report that can be run by any user on an ad hoc basis. Allocating the required memory to any session on demand is not feasible in this environment. In the end , it seems to me that a more sustainable solution will be to introduce an additional table to carry the summarized values and lookup on that table in this type of scenario. Regards -- View this message in context: http://postgresql.1045698.n5.nabble.com/Performance-issue-index-not-used-on-GROUP-BY-tp5816702p5817622.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance