Re: performance with triggers depends on table size? - Mailing list pgsql-general

From Manfred Koizar
Subject Re: performance with triggers depends on table size?
Date
Msg-id vpcllucv5ka7gp1keg4jmqc6rpbf4i6964@4ax.com
Whole thread Raw
In response to Re: performance with triggers depends on table size?  (Christian Mock <cm@coretec.at>)
Responses Re: performance with triggers depends on table size?  (Christian Mock <cm@coretec.at>)
List pgsql-general
On Wed, 14 Aug 2002 19:53:19 +0200, Christian Mock <cm@coretec.at>
wrote:
>Where's the big number of "Deleted" tuples coming from?

From repeatedly
>   UPDATE event_stats SET count = count + x_count
>    WHERE stat_id = result.stat_id;

Due to MVCC Postgres treats an UPDATE much like a DELETE and an
INSERT.  I suspect the deleted tuples get in the way, when the UNIQUE
constraint is checked.  This explains the linear increase of time per
tuple.  I guess you are inserting sorted by (c1, c2, c3) - or at least
in large chunks of equal (c1, c2, c3) -  and the "drops" in your
diagram occur whenever (c1, c2, c3) - or whatever the unique columns
on event_stats are - changes.

For now you have already found a solution/workaround.  In 7.3 this can
be expected to work better.

Servus
 Manfred

pgsql-general by date:

Previous
From: Alex Rice
Date:
Subject: Perl modules problem on OS X
Next
From: Tom Jenkins
Date:
Subject: PG 7.2.1 core dump