X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 0381D9F9FE3 for ; Sat, 24 Jun 2006 01:28:44 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 73732-10 for ; Sat, 24 Jun 2006 01:28:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from wolff.to (wolff.to [66.93.197.194]) by postgresql.org (Postfix) with SMTP id 08C729F9AD3 for ; Sat, 24 Jun 2006 01:28:37 -0300 (ADT) Received: (qmail 14494 invoked by uid 500); 24 Jun 2006 04:32:27 -0000 Date: Fri, 23 Jun 2006 23:32:27 -0500 From: Bruno Wolff III To: John Vincent Cc: Mark Lewis , PGSQL Performance Subject: Re: Optimizer internals Message-ID: <20060624043227.GA13888@wolff.to> Mail-Followup-To: Bruno Wolff III , John Vincent , Mark Lewis , PGSQL Performance References: <1150396425.31200.66.camel@archimedes> <1150398064.31200.76.camel@archimedes> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/470 X-Sequence-Number: 19827 On Thu, Jun 15, 2006 at 15:38:32 -0400, John Vincent wrote: > Any suggestions? FYI the original question wasn't meant as a poke at > >comparing PG to MySQL to DB2. I'm not making an yvalue judgements either > >way. I'm just trying to understand how we can use it the best way possible. > > > > Actually we just thought about something. With PG, we can create an index > that is a SUM of the column where indexing, no? We're going to test this in > a few hours. Would that be able to be satisfied by an index scan? No, that won't work. While you can make indexes on functions of a row, you can't make indexes on aggregate functions. You might find making a materialized view of the information you want can help with performance. The issues with "sum" are pretty much the same ones as with "count". You can find a couple different ways of doing materialized views for "count" in the archives. There is a simple way of doing it that doesn't work well with lots of concurrent updates and a more complicated method that does work well with lots of concurrent updates.