| From: | Andrew Sullivan <andrew(at)libertyrms(dot)info> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: for help! |
| Date: | 2003-04-16 15:53:12 |
| Message-ID: | 20030416155312.GF19999@libertyrms.info |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Apr 16, 2003 at 08:48:36AM -0700, Josh Berkus wrote:
> Scott,
>
> > Well, you can always use the trick of putting an on insert / delete
> > trigger on the table that maintains a single row table with the current
> > count. That way, whenever a row is added or removed, the count is
> BTW, I tested this for a client. I found the performance penalty
> on inserts and updates to be:
[. . .]
> Please note that the effective performance penalty on inserts and
> updates was dramatically higher for large batches of updates than
> for small ones.
Presumably the problem was to do with contention? This is why I
don't really like the "update one row" approach for this sort of
thing.
But you _could_ write a trigger which inserts into a "staging" table,
and write a little daemon which only updates the count table with the
data from the staging table. It's a mighty ugly hack, but it ought
to work.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-04-16 16:01:56 | Re: for help! |
| Previous Message | Josh Berkus | 2003-04-16 15:48:36 | Re: for help! |