Re: A performance tip

Bill Tutt wrote:

The smaller our BDB transactions are the better off our datastore will
be for scalability. As far as I know, BDB doesn't let us get away with
doing dirty reads (no read lock was acquired) on known non-changeable
data. BDB also doesn't do lock escalation. I don't recall whether or not
BDB supports row locks or not. It might only support page locks. If
that's the case the smaller our BDB transactions the less time we hold
read locks open that prevent writing threads from getting about their
business of creating new Subversion transactions (or whatever).
  

I started wondering yesterday if we couldn't simple blow away most of
our transactions anyway.

Most of the data in the filesystem is read-only. The only times we
really need transactions are

    * acquiring new unique keys in the tables that use the next-id hack
    * commits of mutable txns
    * changes to the representation skels during
      deltification/undeltification

We don't even have to make a mutable node within a transaction, since
the source node is read-only and the target is within a txn that we know
is being modified serially, by only one client.

For things like reading string contents, it would be much better to use
locks rather than transactions. That doesn't involve the logging and
fsync overhead. It's really stupid that the BDB log files keep growing
even when people are only reading from the repository.

Somebody please tell me I'm totally mad...

-- 
Brane Čibej   brane_at_xbc.nu   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org