On Thu, 2007-11-29 at 11:43 -0500, Christopher Browne wrote:
> Simon Riggs <simon at 2ndquadrant.com> writes:

> > - Why do we DELETE log table rows at all? We're doing it out-of-line so
> > it clearly isn't a necessary step for correctness (or is it?). At the
> > end of it all we TRUNCATE them anyway, so what was the point of all that
> > deletion? Or alternatively, why do we truncate and log switch at all?
> 
> The older/original logic would simply use DELETE, never TRUNCATING;
> originally, we were just using the one log table, so there wasn't any
> option of doing a TRUNCATE.
> 
> I was trying to be as conservative/safe as possible when I changed things
> to add in periodic truncation of log tables.

Understood. Stability is a key strength of slony and one that makes it
very popular as a result. <action>Tip-of-the-hat</action>

> Yes, you're right, we could solely use TRUNCATE, never using DELETE.
> That sounds like a good further incremental change to propose.

Cool.

> > - My understanding of the flip-flop design with 2 log tables was that it
> > would allow us to avoid VACUUM entirely, yet this doesn't seem to be the
> > case in 1.2. What purpose does the second log table serve?
> 
> That's not exactly it; what it provides is that if we can periodically
> TRUNCATE log tables, then we can be certain that they do not
> permanently bloat to any ridiculous size.
> 
> It's not, in effect, that we can get a "best case;" instead, we get to
> avoid a "worst case."

So it sounds like we could have both:

Have the cleanup_thread measure the size of the log table. If it exceeds
a specified size then we DELETE, otherwise we just wait for TRUNCATE. If
people have enough space they can just let the table build up and let it
be truncated when we switch log tables.

So we have the worst case avoidance mechanism, but also a best case
performance gain because we avoid all that annoying DELETE and VACUUM
activity which drags down response times.

What do you think?

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com