Skip site navigation (1) Skip section navigation (2)

Re: Minimizing dead tuples caused by update triggers

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dan Harris <fbsd(at)drivefaster(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Minimizing dead tuples caused by update triggers
Date: 2007-12-20 01:54:12
Message-ID: C0FED37D-7CC9-4D3E-BB1F-D8DB685E9E2D@decibel.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Dec 19, 2007, at 6:39 PM, Tom Lane wrote:
>> The thing that concerns me is dead tuples on the table_stats  
>> table.  I
>> believe that every insert of new data in one of the monitored tables
>> will result in an UPDATE of the table_stats table.  When thousands
>> ( or millions ) of rows are inserted, the select performance ( even
>> trying with an index ) on table_stats slows down in a hurry.
>
> Yup.  FWIW, 8.3's "HOT" tuple updates might help this quite a lot.
> Not a lot to be done about it in 8.0.x though :-(


A work-around others have used is to have the trigger just insert  
into a 'staging' table and then periodically take the records from  
that table and summarize them somewhere else. You still have a vacuum  
concern on the staging table, but the advantage is that you trigger  
path is a simple insert instead of an update, which is effectively a  
delete and an insert.

This is a case where a cron'd vacuum that runs once a minute is  
probably a wise idea.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828


In response to

Responses

pgsql-performance by date

Next:From: Joshua D. DrakeDate: 2007-12-20 04:25:56
Subject: Re: Dual core Opterons beating quad core Xeons?
Previous:From: Decibel!Date: 2007-12-20 01:51:13
Subject: Re: Dual core Opterons beating quad core Xeons?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group