Re: no index-usage on aggregate-functions?

> Note that there ARE other options. While the inability to provide a
> speedy count is a "cost" of using an MVCC system, the ability to allow
> thousands of readers to run while updates are happening underneath them
> more than makes up for the slower aggregate performance.

IMO this depends on the priority of your application resp. the customers intentions and wishes

> This, however, is not paradise.

you can't have it all ;-)

> On the contrary, it makes it GREAT for datawarehousing. Not because any
> one child process will be super fast, but because ALL the child
> processes will run reasonably fast, even under very heavy read and write
> load.

What I meant with datawarehouse are many db's at many locations whose data are to be collected in one central db in order to mix em up, sum up or do anything equivalent.
But in fact my quite heavy-read/write-accessed db is running really fast since 1 1/2 years now
Even though still on PG 7.2
The one and only bottleneck are the statistics and the reports - and the tables are getting larger and larger ...

> Note that if you've got the memory for the hash agg algo to fire
> into shared memory, it's pretty darned fast now,

yes, I've noticed here on the testing server

> so if the data (mostly)
> fit into kernel cache you're gold. And 12 gig Intel boxes aren't that
> expensive, compared to an Oracle license.

*that's* the point ...

Anyway: Greetings and thanks for your answers
Harald