You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/11/19 16:09:10 UTC
Re: (warning: bikeshed) Naming mergeinfo.db.
On Sep 19, 2007 12:19 PM, Malcolm Rowe <ma...@farside.org.uk> wrote:
> Secondly, I wonder what we'll do when we want to add more derived
> information to the filesystem (e.g. someone [I forget who, sorry] showed
> a proof-of-concept SQLite property indexer a while back). Will we
> create another SQLite database?
>
> So, I propose we rename mergeinfo.db to something more generic: say,
> indexes.db. You can all lynch me now.
While there are aesthetic reasons for this change, I'm not sure that
the argument of "we'll have more indexes so they should all go in
index.sqlite" makes sense. I just added a second index to
indexes.sqlite (for the node-origins query); however, this data and
the mergeinfo are pretty independent, have different caching
semantics, and won't be joined against each other, so in the interests
of throughput (because sqlite3 locks entire db files, not tables), I
propose we revert r26947 and keep mergeinfo.sqlite and
node-origins.sqlite in separate files.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: (warning: bikeshed) Naming mergeinfo.db.
Posted by David Glasser <gl...@davidglasser.net>.
On Nov 21, 2007 5:03 PM, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
>
> > While there are aesthetic reasons for this change, I'm not sure that
> > the argument of "we'll have more indexes so they should all go in
> > index.sqlite" makes sense. I just added a second index to
> > indexes.sqlite (for the node-origins query); however, this data and
> > the mergeinfo are pretty independent, have different caching
> > semantics, and won't be joined against each other, so in the interests
> > of throughput (because sqlite3 locks entire db files, not tables), I
> > propose we revert r26947 and keep mergeinfo.sqlite and
> > node-origins.sqlite in separate files.
>
> +1, please do it. These operations have no business at all
> blocking each other.
My head is deep in some other code right now, and it's not 100%
trivial (it'll require changing some of the sqlite util functions to
take extra params, etc), but I'll do it on Monday at the latest.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: (warning: bikeshed) Naming mergeinfo.db.
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"David Glasser" <gl...@davidglasser.net> writes:
> While there are aesthetic reasons for this change, I'm not sure that
> the argument of "we'll have more indexes so they should all go in
> index.sqlite" makes sense. I just added a second index to
> indexes.sqlite (for the node-origins query); however, this data and
> the mergeinfo are pretty independent, have different caching
> semantics, and won't be joined against each other, so in the interests
> of throughput (because sqlite3 locks entire db files, not tables), I
> propose we revert r26947 and keep mergeinfo.sqlite and
> node-origins.sqlite in separate files.
+1, please do it. These operations have no business at all
blocking each other.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org