Re: Prefetch

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: pgsql-performance(at)postgresql(dot)org, molson(at)oceanconsulting(dot)com, Sam Vilain <sam(at)vilain(dot)net>
Subject: Re: Prefetch
Date: 2005-05-11 13:42:30
Message-ID: 1115818950.725.6.camel@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 2005-05-11 at 12:53 +0800, Christopher Kings-Lynne wrote:
> > Another trick you can use with large data sets like this when you want
> > results
> > back in seconds is to have regularly updated tables that aggregate the data
> > along each column normally aggregated against the main data set.
>
> > Maybe some bright person will prove me wrong by posting some working
> > information about how to get these apparently absent features working.
>
> Most people just use simple triggers to maintain aggregate summary tables...

Agreed. I've also got a view which calls a function that will 1) use the
summary table where data exists, or 2) calculate the summary
information, load it into summary table, and send a copy to the client
(partial query results cache).

It's not all nicely abstracted behind user friendly syntax, but most of
those features can be cobbled together (with effort) in PostgreSQL.
--

In response to

  • Re: Prefetch at 2005-05-11 04:53:05 from Christopher Kings-Lynne

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-05-11 13:57:07 Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
Previous Message Tom Lane 2005-05-11 13:27:57 Re: Partitioning / Clustering