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

Re: SQL indices a WC format bump and 1.7

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 03 Oct 2011 10:03:53 +0100

Branko Čibej <brane_at_xbc.nu> writes:

> On 02.09.2011 22:56, Greg Stein wrote:
>> On Fri, Sep 2, 2011 at 13:18, Mark Phippard <markphip_at_gmail.com> wrote:
>>> Pardon my ignorance, but in a scenario like this where we want to just
>>> change some of the indexes, aren't we able to just bump the WC format
>>> on the fly automatically? IOW, can't we just make a format 30 with
>>> all these index changes and have it automatically upgrade any format
>>> 29 WC it comes across?
>> We cannot bump the format during the 1.7.x series because 1.7.0 would
>> not understand format N+1 produced by (say) 1.7.2.
>> One thing that we could do: have 1.7.x "understand" all formats from
>> 29 through 39. We only make changes that are both forward and backward
>> compatible (e.g. presence/absence of an index does not affect 1.7.x
>> from using the wc.db). For 1.8.0, we autobump to format 40 with our
>> various changes.
> Wouldn't it just be easier to look at the actual database to see if the
> indexes are there. Adding an index does not change the database schema,
> only query performance (hopefully for the better). Therefore it doesn't
> require a format bump.

The SQL that would have made use of the index is probably broken (I'm
not enough of an SQLite expert to say for sure). There is a better
solution on trunk--it changed the SQL and does some processing in C and
so does not require an index. The change has been proposed for backport
to 1.7 but not yet accepted. It's possible to fix the 1.7 performance
problem by manually adding the index to a 1.7 wc, but that leaves the
broken (?) SQL.

uberSVN: Apache Subversion Made Easy
Received on 2011-10-03 11:04:31 CEST

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.