Re: Minimizing dead tuples caused by update triggers
От | Decibel! |
---|---|
Тема | Re: Minimizing dead tuples caused by update triggers |
Дата | |
Msg-id | C0FED37D-7CC9-4D3E-BB1F-D8DB685E9E2D@decibel.org обсуждение исходный текст |
Ответ на | Re: Minimizing dead tuples caused by update triggers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Minimizing dead tuples caused by update triggers
|
Список | 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@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
Вложения
В списке pgsql-performance по дате отправления: