Re: performance with triggers depends on table size?

On Wed, Aug 14, 2002 at 10:05:00PM +0200, Manfred Koizar wrote:

> 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

I see; thanks to you and Jochem for explaining.

> 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

There's a huge amount of clustering in the data, ATM I've got some 2 mio
rows in the output table and less than 1000 in the stats table; I don't
think they're inserted in equal chunks, but in the real database structure
there's some single-colum indexes on the event_stats table, e.g. on
the hour column, and data is inserted in chronological order.

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

So this means my kludgy solution is as good as it can get ATM? That
would mean going back to boring CGI script coding instead of fiddling
with performance :-/

Thanks a lot,

cm.

--
Christian Mock Wiedner Hauptstrasse 15
Senior Security Engineer 1040 Wien
CoreTEC IT Security Solutions GmbH +43-1-5037273