Re: Much Ado About COUNT(*)

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Much Ado About COUNT(*)
Date: 2005-01-19 20:40:53
Message-ID: 20050119204053.GJ32192@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 19, 2005 at 10:16:38AM -0600, Bruno Wolff III wrote:
> On Wed, Jan 19, 2005 at 14:59:17 -0000,
> Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> wrote:
>
> > So then I would use SELECT COUNT(*) FROM person_count whenever I wanted to
> > know the current number of person records. How much quicker would a COUNT(*)
> > be if visibility were included in the indices as opposed to a "hacked"
> > approach like this?
>
> You are only going to get a constant factor speed up unless the space savings
> allows much better use of cache. You probably want to look at using
> triggers to maintain counts in another table.

I'd try using a "start value" and a differences list. So the
differences list would be initially empty and the start value would be
0. On insert or delete, you create a new difference (with +1 or
whatever). Periodically, the differences would be added to the start
value and the records deleted. Thus the time to calculate the total
count is much smaller, and it follows MVCC rules. Of course there are
lots of minor details not mentioned here.

Not sure if I'd model this with a single table or two.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"I would rather have GNU than GNOT." (ccchips, lwn.net/Articles/37595/)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2005-01-19 20:58:55 Re: Two-phase commit for 8.1
Previous Message Heikki Linnakangas 2005-01-19 18:55:57 Two-phase commit for 8.1