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

Re: Streamy FS writes found detrimental.

From: Daniel Berlin <dan_at_dberlin.org>
Date: 2002-02-26 20:57:23 CET

On Tue, 2002-02-26 at 14:00, Branko ╚ibej wrote:
> cmpilato@collab.net wrote:
>
> >I'm, really, really bothered by this. Anybody have any suggestions on
> >what to do about it? Perhaps I should do some sort of in-between
> >thing where the filesystem caches writes up to some size (say, 1
> >megabyte) and then flushes to Berkeley? I'll entertain all
> >suggestions -- the current behavior is ridiculous, and I'd rather not
> >have streamy writes at all if this is the price we pay.
> >
> I described the solution to Greg on irc yesterday -- take the fulltexts
> out of the database, and put them into the filesystem.

Bad.
This removes the ability to replicate easily, etc.

The problem isn't the fact that the ft's are in the database.
The problem is that, among other things, the db cache size is 256k by
default.

There is 0 reason to remove fulltexts from the db.

 Of course, I was
> worried about DB object size limits, not transaction logs -- but this
> solutino fixes both problems.

The db object sizes are only limited by available memory (assuming you
are doing non-partial object fetches), but are otherwise unlimited
length.

 We lose transaction control on fulltext
> contents -- but so what, we don't need it anyway.
>
> --
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:10 2006

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.