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 20020814175318.GC20936@notemock.coretec.at
Whole thread Raw
In response to Re: performance with triggers depends on table size?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: performance with triggers depends on table size?  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-general
On Wed, Aug 14, 2002 at 09:35:31AM -0400, Tom Lane wrote:

> Interesting ... I'd have to guess that there is some external influence
> causing that.  Do you by any chance have a cron jon set up to do
> "vacuum"s periodically, and if so do the vacuums correspond to the
> points where the insertion time drops?

I can't seem to see any external influences; there is a once-a-night
vacuum run from cron, which fits with one of the sawtooth "drops",
but it still doesn't explain the other teeth. (And I checked the
postgres log for signs of other vaccum runs, there are none).

The database, and the machine it's running on, is otherwise quiescent.

After an afternoon of playing around, I found I can keep the performance
up (at least for 50000 rows) if I do

  BEGIN;
  INSERT INTO ac_event SELECT * FROM in_event WHERE eid < x AND eid > y;
  COMMIT;
  VACUUM ANALYZE event_stats;

in a tight loop, where the number of rows selected by x and y is very
small -- about 100 or less (and this is with the script not running
on the DB machine).

What I also noticed on verbose vacuums on the event_stats table is that
there's always a relatively big number of "Deleted" tuples, which has
some correlation to the number of rows copied in the previous insert;
interestingly, if x and y are 1000 apart, but there's "holes" in
in_event and fewer rows get copied, "Deleted" is less than the number
of rows copied, but with 1000 rows copied, it is at 1000 straight.

Where's the big number of "Deleted" tuples coming from? The relevant part
of the trigger function is below, the "DELETE" code path should never be
chosen (and from watching the sequence for the stat_id column, which
is completely in line with "count(*) from event_stats", it never is). Is
the update (on the non-indexed column "count" only) causing this?

I hope one of you gurus can make something out of this data...

regards,

cm.

  x_hour := date_trunc(''hour'', $5);
  SELECT INTO result stat_id, count FROM event_stats
   WHERE sensor_id = x_sensor_id AND ip_src = x_ip_src AND ip_dst = x_ip_dst
   AND sig_id = x_sig_id AND hour = x_hour AND type = x_type;
  IF NOT FOUND THEN
   INSERT INTO event_stats (sensor_id,ip_src,ip_dst,sig_id,hour,type,count)
    VALUES(x_sensor_id,x_ip_src,x_ip_dst,x_sig_id,x_hour,x_type,x_count);
  ELSE
   UPDATE event_stats SET count = count + x_count
    WHERE stat_id = result.stat_id;
   IF (result.count + x_count) = 0 THEN
    DELETE FROM event_stats WHERE stat_id = result.stat_id;
   END IF;
  END IF;

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

pgsql-general by date:

Previous
From: Greg Copeland
Date:
Subject: SF moving to DB2...
Next
From: Bruce Momjian
Date:
Subject: Re: cvs postgresql current lacks 'ksqo' ? odbc/pgadmin does