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
http://www.uberSVN.com
Received on 2011-10-03 11:04:31 CEST