[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Keith Bostic <bostic@sleepycat.com>] Re: [#6254] log optimization for record append

From: <cmpilato_at_collab.net>
Date: 2002-07-15 15:15:27 CEST

For those who might be interesed, remember long ago when Greg Stein
switched our Berkeley `strings' table over to a duplicate-key
database? The reason was that we were getting exponential log growth
and slow access rates using the append-another-chunk-of-data-to-
an-existing-row approach that we *had* been using.

Well, here's some insider info on why we were seeing exponential
growth for append operations (something we felt we shouldn't be

------- Start of forwarded message -------
Date: Thu, 11 Jul 2002 21:41:17 -0400 (EDT)
From: Keith Bostic <bostic@sleepycat.com>
Message-Id: <200207120141.g6C1fHr17247@abyssinian.sleepycat.com>
To: cmpilato@collab.net
Subject: Re: [#6254] log optimization for record append
Cc: striker@apache.org, support@sleepycat.com

> I'll make an attempt.
> Basically we were populating a single row's value in chunks -- a
> looping codepath that wrote so many bytes of data to the end of what
> had already been written. If memory serves, this was done with
> regular DB->put calls using a DBT with the DB_DBT_PARTIAL flag. So,
> for example, an unrolled loop might look like:

I think we understand now -- Berkeley DB does not do any kind
of prefix or suffix logging optimizations for overflow records,
that is, records too large to fit on the standard Btree pages.

So, yes, I agree this scenario would result in enormous log

Thank you for explaining this one to us!


Keith Bostic
Sleepycat Software Inc. bostic@sleepycat.com
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

------- End of forwarded message -------

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 03:17:37 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.