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

From Christian Mock
Subject Re: performance with triggers depends on table size?
Date
Msg-id 20020815001710.GA23284@notemock.coretec.at
Whole thread Raw
In response to Re: performance with triggers depends on table size?  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: performance with triggers depends on table size?  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-general
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

pgsql-general by date:

Previous
From: "Johnson, Shaunn"
Date:
Subject: database tuning
Next
From: Tom Lane
Date:
Subject: Re: database tuning