On Tuesday November 2 2004 6:15, Jan Wieck wrote:
> On 11/2/2004 1:08 AM, Ed L. wrote:
> > I have a 2-node master-slave replication set up with 1.0.5.  It's been
> > running for a couple days.  The sl_seqlog table is now 75MB.  Is this
> > expected?  How much larger will it grow?  What causes it to get cleaned
> > up?
>
> Don't take this wrong, Ed, it is certainly appreciated to point out
> possible problems with Slony. But maybe you could direct a little bit of
> the energy, you spend on making sure anybody understands the problem you
> have with your 200 seldom updated sequences, into studying the code and
> finding a solution to it that is not disruptive for people with few high
> frequent accessed sequences.

Don't take this wrong, Jan, your Slony work is certainly much appreciated.  
But maybe you could direct a little bit of the energy you spend on cheap 
shots like this into engaging in discussion of the merits of the ideas put 
forth.  I have, in fact, done what you suggest all along, and have simply 
responded with rational argument to those arguments put forth by others.  
If you think any implementation of sequence triggers would likely be 
counter-productive for frequently-accessed sequences, just say so.  If you 
don't care for any solution other than polling, then just say why, don't 
take aim at my effort.  If you agree with Andrew's assessment, just say so.  
If you don't like the thread, don't read it, but I sure don't appreciate 
your attempt to try to stifle my input or judgmentally criticize my effort 
because you don't like my idea.  If you don't think sequence performance is 
worth addressing, just say why.  I welcome and appreciate civil criticism 
of my ideas on rational grounds; I do not welcome criticism of my efforts, 
about which you know next to nothing.  

As for my "200 seldom updated sequences", you are simply mistaken.  I 
suspect you have few users who pound Pgsql (and sequences) as hard as we 
do.  We have many frequently-accessed sequences among some 50 high-volume 
Pgsql clusters, constituting an aggregate of roughly 5000 queries/second 
over a terabyte of data at large facilities around the U.S., and we are 
continually pressed for better performance.  I have looked at the code 
considerably, but ultimately, I am primarily a Slony user, not a Slony 
developer.  I do not have time to learn the code as you and others know it, 
though I have, in fact, submitted a few minor patches to both code and 
documentation.  I do regularly make an effort to think carefully, look for 
a possible code patch I might add, and read your docs before raising 
issues; that's a bit tricky because the documentation as I know it is 
hap-hazardly spread among at least 4 separate sources (tar ball, gborg, 
elein, wiki).  I'm on your side here; save the cheap shots for people who 
are trying to tear you down, not the people trying to help your effort.
 
> The cleanup is of course done in src/slon/cleanup_thread.c including the
> vacuuming. Slon never issues a full vacuum, so shrinking of any related
> tables will only happen ever if you configured a sufficient freespace
> map and that results in free blocks at the end of the relation for
> successive vacuum cycles, which happen every 10 minutes.

Thank you.