Message-ID: <452DE6E7.6050808@logix-tt.com>
Date: Thu, 12 Oct 2006 08:55:35 +0200
From: Markus Schaber <schabi@logix-tt.com>
Organization: Logical Tracking and Tracing International AG, Switzerland
User-Agent: Thunderbird 1.5.0.7 (X11/20060927)
MIME-Version: 1.0
To: brendan.curran@gmail.com
Cc: AgentM <agentm@themactionfaction.com>,
	Pg Performance list <pgsql-performance@postgresql.org>
Subject: Re: Scrub one large table against another (vmstat output)
References: <452C1437.9040709@gmail.com>
	<63AAE7DF-0D71-4BE7-A62C-B08E7E3C35CE@themactionfaction.com>
	<452C252C.2030408@gmail.com>
	<C03C1953-A8D1-48E8-B5EE-AAD9FA473D60@themactionfaction.com>
	<452C3A54.7000908@gmail.com>
	<ACA00F4F-8AD1-4F04-9C24-47F615DB0DC3@themactionfaction.com>
	<452D28EE.6000105@gmail.com>
In-Reply-To: <452D28EE.6000105@gmail.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Hi, Brendan,

Brendan Curran wrote:
>> What prevents you from using an aggregate function?
> 
> I guess I could actually obtain the results in an aggregate function and
> use those to maintain a summary table. There is a web view that requires
> 'as accurate as possible' numbers to be queried per group (all 40 groups
> are displayed on the same page) and so constant aggregates over the
> entire table would be a nightmare.

That sounds just like a case for GROUP BY and a materialized view.

Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org