On Thu, Oct 11, 2007 at 11:17:17AM +0200, Markus Schiltknecht wrote:
> But I doubt very much that there are any gains. The index on
> revision_certs(id) should be enough, as we have only few (in most cases
> four) revision_certs per revision id.
Measurement beats guessing :-).
> I'm not an expe
Hi,
Ralf S. Engelschall wrote:
Monotone showed just _warning_ messages but operated just fine.
Strange, the following error message should be returned:
mtn: misuse: /home/markus/.monotone.36.ind.db appears to be a monotone
database, but this version of
mtn: misuse: monotone does not recogni
On Wed, Oct 10, 2007, Nathaniel Smith wrote:
> [...]
> [Err... though... waittasec. Shouldn't the database upgrade machinery
> be causing mtn to bomb out on your modified database ("unrecognized
> schema version" or the like)? Did you disable that or something?]
Monotone showed just _warning_ m
On Wed, Oct 10, 2007 at 08:07:26PM +0200, Ralf S. Engelschall wrote:
> What do we think? Should we investigate further and especially add
> additional indices like the above to the Monotone database schema? Or is
> there consensus that this type of speed optimization is just the root of
> furthcomi
On Wed, Oct 10, 2007, Bruce Stephens wrote:
> Chad Walstrom <[EMAIL PROTECTED]> writes:
>
> [...]
> > Would there be a way to tell sqlite to ignore indices for given
> > operations, such as pulls?
>
> That strikes me as a low-level question that should be ignored (at
> least unless it causes some
On Wed, Oct 10, 2007, Justin Patrin wrote:
> On 10/10/07, Ben Walton <[EMAIL PROTECTED]> wrote:
> > Indexes speed up read operations but slow down writes. Which do we do
> > more of? I'd optimize for the case that would benefit most. I
> > suspect we do a fair amount of both. In this case, may
Chad Walstrom <[EMAIL PROTECTED]> writes:
[...]
> Would there be a way to tell sqlite to ignore indices for given
> operations, such as pulls?
That strikes me as a low-level question that should be ignored (at
least unless it causes some measurable problem).
One would hope that SQLite will only
Ralph wrote:
> CREATE INDEX revision_certs__id_name_value ON
>revision_certs (id, name, value);
> CREATE INDEX public_keys__id ON
>public_keys (id);
>
> This dropped down the total execution time of the mentioned "mtn update"
> command by over 80%!
Ben wrote:
>
On 10/10/07, Ben Walton <[EMAIL PROTECTED]> wrote:
> Indexes speed up read operations but slow down writes. Which do we do
> more of? I'd optimize for the case that would benefit most. I
> suspect we do a fair amount of both. In this case, maybe adding
> indexes for mostly-read tables would be
Indexes speed up read operations but slow down writes. Which do we do
more of? I'd optimize for the case that would benefit most. I
suspect we do a fair amount of both. In this case, maybe adding
indexes for mostly-read tables would be the way to go.
-Ben
On 10/10/07, Ralf S. Engelschall <[EM
Some Monotone operations really operate slower than what one would
expect in the first spot. Hence, I've today looked at the run-time of
a simple "mtn update" in a workspace which *is already* at h:n.v.m.
This "no-operation" command internally performs a dozend times the
following SQL queries:
S
11 matches
Mail list logo
