upgrading mysql repositories from format 1.14 to format 2a

Bug #519822 reported by GuilhemBichot on 2010-02-10

This bug report was converted into a question: question #100631: upgrading mysql repositories from format 1.14 to format 2a.

10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Undecided
Unassigned

Bug Description

Hello. I am slowly preparing for the upgrade of our central internal host's shared repository of MySQL branches, from repository format 1.14 to 2a. I would like to use this bug report as the place of resolution of issues faced as I progress (I have already read the 2a upgrade guide).
I just upgraded my local shared repo from 1.14 to 2a with "bzr upgrade --2a" (it took ~8 hours); this local repo is a good approximation of our central repo.
My observations:
                                                    1.14 2a result
size of .bzr 850 MB 300 MB good
(after "bzr pack", and excluding "obsolete_packs")
time for "bzr log -n0" 23 secs 14 secs good
time for "bzr annotate big_file" 12 secs 24 secs bad

I'm using bzr.dev pulled a few days ago.
I think "annotate" is a serious problem, could you please fix the slowdown observed in 2a? My colleagues already complain of the slowness of annotate since we migrated to bzr, I'd rather not make it worse.
If you want to reproduce this: big_file above is sql/mysqld.cc from this branch:
https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase-bugfixing

Then I have general questions. When I'm confident that the new format is good for us, I'll do the migration in steps:
- at T1: ask the 100+ colleagues to install bzr 2.1 (then most will, and a few won't, that happens)
- at T2: upgrade the central shared repo to 2a
- at T3: ask colleagues to upgrade their shared repo (either with "bzr upgrade --2a", or by "scp"-ing a copy of the central repo, to be determined later).
What I wonder is:
1) between T2 and T3, will a colleague with a 1.9/1.14 local repo be able to push to the 2a central repo? to pull from the 2a central repo? to "bzr branch" a branch from the 2a central repo?
2) after T2, will Launchpad mirroring (visible in https://code.launchpad.net/mysql-server) break?
3) after T2, will a colleague using an old bzr (like bzr 1.15) be able to accidentally break something by pushing/pulling to/from the 2a central repo, or will he get a nice error message?
Thanks for your help.

Martin Pool (mbp) wrote :

Hi,

This is more of a set of questions than a bug so I'm going to convert it.

Changed in bzr:
status: New → Invalid
GuilhemBichot (guilhem-bichot) wrote :

Actually there is a bug listed in my text. I pointed out that "annotate" is twice slower in 2a than in 1.14.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Actually there is a bug listed in my text. I pointed out that "annotate"
> is twice slower in 2a than in 1.14.
>

For this specific one, I'd be willing to make it a dupe of bug #153787.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt0D+cACgkQJdeBCYSNAAOEawCdGONh8ShHz6GEITYutpoa/F2E
TpYAoNgP1nLtoe4lDjcGRwd7c/rh9efF
=YYLR
-----END PGP SIGNATURE-----

GuilhemBichot (guilhem-bichot) wrote :

We can go two ways:
1) make it a duplicate of 153787, which is to say, we'll fix the additional 2a slowness when we fix 153787, which isn't assigned. This means that MySQL won't upgrade to 2a before a long time (I cannot sell a 2a upgrade to colleagues if the slow annotate becomes twice slower).
2) evaluate whether fixing only the additional 2a slowness is possible, and possible now, and if so, do it, then we can consider upgrading to 2a.

John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> We can go two ways:
> 1) make it a duplicate of 153787, which is to say, we'll fix the additional 2a slowness when we fix 153787, which isn't assigned. This means that MySQL won't upgrade to 2a before a long time (I cannot sell a 2a upgrade to colleagues if the slow annotate becomes twice slower).
> 2) evaluate whether fixing only the additional 2a slowness is possible, and possible now, and if so, do it, then we can consider upgrading to 2a.
>

The reason 2a is slower is fundamental (we no longer store deltas that
we can extract to generate a diff, which is one step farther than when
we stored the annotation data directly in pre-pack.)

I don't think it is possible to fix without fixing bug #153787
(introduce an annotation cache).

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt0HGQACgkQJdeBCYSNAAMcVQCfSAIt9trRsRUaoYGx1zwTPnNN
p2oAoJDr6D7V8ie27pAWhDAO2BefxDl/
=CHup
-----END PGP SIGNATURE-----

John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> We can go two ways:
> 1) make it a duplicate of 153787, which is to say, we'll fix the additional 2a slowness when we fix 153787, which isn't assigned. This means that MySQL won't upgrade to 2a before a long time (I cannot sell a 2a upgrade to colleagues if the slow annotate becomes twice slower).
> 2) evaluate whether fixing only the additional 2a slowness is possible, and possible now, and if so, do it, then we can consider upgrading to 2a.
>

I should mention that I did spend a fair amount of time here when we
introduced 2a. (It used to be more like 10x slower.) I'm pretty
confident that I reached the limit of what we can achieve without
creating an on-disk cache of intermediate steps.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt0HLAACgkQJdeBCYSNAAMenQCfXV0/plBrHwrqyxvnpxlgdSo3
YYQAoMbcQ10gjCGoa4pi6jcveBnuq8vw
=JIh5
-----END PGP SIGNATURE-----

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers