Re: Speeding up aggregates - Mailing list pgsql-performance

From Joe Conway
Subject Re: Speeding up aggregates
Date
Msg-id 3DF0E825.7020400@joeconway.com
Whole thread Raw
In response to Speeding up aggregates  ("Josh Berkus" <josh@agliodbs.com>)
List pgsql-performance
Josh Berkus wrote:
> While effective, this approach is costly in terms of update/insert
> processing.  It is also limited to whatever aggregate requests you have
> anticipated ... it does no good for aggregates over a user-defined
> range.

I think this is where Oracle's materialized views come into play.

>
> What have other Postgres users done to speed up aggregates on large
> tables?

I've found that in most real life applications, expensive aggregate queries
tend to be needed for management reporting, which does not need to be based on
up-to-the-second fresh data. Normally for these types of reports a summary
through say last night at midnight is perfectly adequate.

The simplest solution in these cases is to build a table to hold your
partially or completely summarized data, then report off of that. Use cron to
refresh these summary tables at convenient times (daily, every 2 hours, or
whatever).

Joe


pgsql-performance by date:

Previous
From: "Josh Berkus"
Date:
Subject: Speeding up aggregates
Next
From: "Josh Berkus"
Date:
Subject: Re: ORDER BY ... LIMIT.. performance