James Black wrote:
> Our proximate reason for moving off of dbmirror -- setting aside the 
> project's quiescent state -- was the rate of growth of the log tables.  
>  Because they were so active (we were seeing maybe 200 
> transactions/minute, in addition to the dbmirror UPDATE/DELETE volume), 
> the tables were ballooning in size, and the SELECT from "Pending" was 
> taking, at our lowest moment, well over 10 seconds.  

Thank you very much. This is the kind of response I expected. My server 
is not so busy, I've go about 25000 transactions during 8 hours period, 
but with about 170 TPM during peak hour. For now I vacuum and reindex 
dbmirror tables every two hours, to keep it small and simple, but I'm 
observing similar problems with long selects.

Today I made a quick & dirty survey comparing dbmirror with Slony and 
here are the results.
I created a small test table with five int columns (a,b,c,d,e) and one 
serial for primary key and filled it with 26000 records. Then I tested 
what I suppose is the worst case for trigger based replication:
UPDATE test set a=a;
So, on my personal computer without any kind of replication it takes:
test=# explain analyze update test5 set a=a;
Total runtime: 582.011 ms

with dbmirror (no DBMirror.pl running):
test=# explain analyze update test5 set a=a;
Total runtime: 29734.181 ms

and with Slony (with slon running)
test=# explain analyze update test5 set a=a;
Total runtime: 2751.073 ms

I must say I'm impressed.
It seems that switching to Slony is my next task.

Once again, thanks for all the responses.
-- 
Marcin