Re: for help!
От | Josh Berkus |
---|---|
Тема | Re: for help! |
Дата | |
Msg-id | 200304160848.36431.josh@agliodbs.com обсуждение исходный текст |
Ответ на | Re: for help! ("scott.marlowe" <scott.marlowe@ihs.com>) |
Ответы |
Re: for help!
|
Список | pgsql-performance |
Scott, > Well, you can always use the trick of putting an on insert / delete > trigger on the table that maintains a single row table with the current > count. That way, whenever a row is added or removed, the count is > updated. this will slow down inserts and deletes a little, but TANSTAAFL. BTW, I tested this for a client. I found the performance penalty on inserts and updates to be: -- For a single stream of intermittent updates from a single connection on an adequately powered server with moderate disk support (IDE Linux RAID) (100 inserts/updates per minute, with VACUUM every 5 minutes) PL/pgSQL Trigger: 20% penalty C Trigger: 9-11% penalty -- For 5 streams of inserts and updates at high volume on an overloaded server with moderate disk support (dual fast SCSI disks) (1000 inserts/updates per minute, vacuum every 5 minutes) PL/pgSQL Trigger: 65% penalty C Trigger: 40% penalty Please note that the effective performance penalty on inserts and updates was dramatically higher for large batches of updates than for small ones. -- Josh Berkus Aglio Database Solutions San Francisco
В списке pgsql-performance по дате отправления: