Re: Speedier count(*)

From: Tino Wildenhain
Subject: Re: Speedier count(*)
Date: ,
Msg-id: 1123745049.27613.1.camel@Andrea.peacock.de
(view: Whole thread, Raw)
In response to: Re: Speedier count(*)  (Mark Cotner)
Responses: Re: Speedier count(*)  (Gavin Sherry)
List: pgsql-performance

Tree view

Speedier count(*)  (Dan Harris, )
 Re: Speedier count(*)  ("Joshua D. Drake", )
 Re: Speedier count(*)  (Michael Fuhr, )
 Re: Speedier count(*)  (John A Meinel, )
 Re: Speedier count(*)  (Gavin Sherry, )
  Re: Speedier count(*)  (Mark Cotner, )
   Re: Speedier count(*)  (Tino Wildenhain, )
    Re: Speedier count(*)  (Gavin Sherry, )
     Re: Speedier count(*)  (Tino Wildenhain, )
      Re: Speedier count(*)  (PFC, )
       Re: Speedier count(*)  (Tino Wildenhain, )
        Re: Speedier count(*)  (Dan Harris, )

Am Donnerstag, den 11.08.2005, 00:40 -0400 schrieb Mark Cotner:
> Here's a trigger I wrote to perform essentially the same purpose.  The nice
> thing about this is it keeps the number up to date for you, but you do incur
> slight overhead.
...
>
> CREATE TRIGGER del_rowcount_tr BEFORE DELETE ON test FOR EACH ROW EXECUTE
>    PROCEDURE del_rowcount();
> CREATE TRIGGER add_rowcount_tr BEFORE INSERT ON test FOR EACH ROW EXECUTE
>    PROCEDURE add_rowcount();
>
> INSERT INTO rowcount (tablename) VALUES ('test');
...

beware of problems with concurrency and even what happens
if transactions roll back. Maybe you can "fix" it a bit
by regulary correcting the count via cronjob or so.



pgsql-performance by date:

From: Steve Poe
Date:
Subject: [SPAM?] Re: PG8 Tuning
From: Ian Westmacott
Date:
Subject: Re: Planner doesn't look at LIMIT?