Re: Slow COUNT

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tino Wildenhain <tino(at)wildenhain(dot)de>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>, Guido Neitzer <guido(dot)neitzer(at)pharmaline(dot)de>, pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Slow COUNT
Date: 2005-12-05 01:04:32
Message-ID: 87wtikcq1r.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tino Wildenhain <tino(at)wildenhain(dot)de> writes:

> Am Sonntag, den 04.12.2005, 09:56 -0600 schrieb Bruno Wolff III:
> > On Sun, Dec 04, 2005 at 14:40:49 +0100,
> >
> > Assuming you are refering to max and min, this has already been done and is
> > in 8.1.
>
> I also mean sum, avg, ... and last not least count :-)

The naive implementation would mean serializing all table updates. In other
words only one person can update, insert, or delete at a time. Until that user
commits everybody else would be locked out of the table. You may as well be
using something like mysql then if that's acceptable.

The more sophisticated implementation would require customization to get
right. It requires a second table keeping track of deltas and a periodic job
aggregating those deltas. Which aggregates to put in it, how often to
aggregate them, and when to consult them instead of consulting the main table
would all be things that would require human intervention to get right.

It would be cool if there were a shrinkwrapped package, perhaps in contrib, to
do this with knobs for the user to play with instead of having to roll your
own. perhaps in contrib. But nobody's done a good enough version yet to
consider it.

--
greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Sabino Mullane 2005-12-05 01:19:01 Re: 8.1, OID`s and plpgsql
Previous Message vishal saberwal 2005-12-05 00:55:47 Selecting Large Object and TOAST