649123 - Run ANALYZE on dirty places.sqlite files

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Shawn Wilsher :sdwilsh]

Somewhat similar to bug 600980, I'd like to have us run the following commands on our dirty places.sqlite files:
ANALYZE moz_places
ANALYZE moz_bookmarks
ANALYZE moz_historyvisits
ANALYZE moz_inputhistory

This is likely to change performance numbers, but will bring out testing environment more inline with what we ship to users after bug 599641.

Comment 1

[alice nodelman [:alice] [:anode]]

Is this a one-off or something that you want done periodically?

Comment 2

[Shawn Wilsher :sdwilsh]

(In reply to comment #1)
> Is this a one-off or something that you want done periodically?
It's a one-off (unless we change the contents, and then it's probably a good idea to update it every so often).

Comment 3

[Shawn Wilsher :sdwilsh]

I should also elaborate...

After this command is ran, sqlite_stat1 should be populated with data.  If sqlite_stat2 is populated, that means the client that was used is compiled differently than what we are shipping with.

Comment 4

[Marco Bonardo [:mak]]

I think we should update the script that generates the db to run this as last step. See also bug 635474 for a needed update.
I don't think as it is now this is going to be super-useful, since the database contents are pretty much far from what a user would have (140 000 bookmarks in a single folder).

Alice, could you please point me again at the generate-db script on mxr?

Comment 5

[alice nodelman [:alice] [:anode]]

mak: http://hg.mozilla.org/build/tools/file/94b8d1b63c3e/buildfarm/utils/generator

Comment 6

[Shawn Wilsher :sdwilsh]

(In reply to comment #4)
> I don't think as it is now this is going to be super-useful, since the database
> contents are pretty much far from what a user would have (140 000 bookmarks in
> a single folder).
Remember that there are three different dirty databases ;)

Comment 7

[Marco Bonardo [:mak]]

Yes, and all of three are quite far from a common user database.

Comment 8

[alice nodelman [:alice] [:anode]]

Scheduled to make the change on Friday April 29th at 3pm PST.

Comment 9

[alice nodelman [:alice] [:anode]]

Turns out that I no longer have access to the vm that hosts the dirty profiles, the work will have to be done by someone with releng access.

Comment 10

[Mike Taylor [:bear]]

Alice,

Same with this, can you give me more detail on where/how to do this?

Comment 11

[alice nodelman [:alice] [:anode]]

Requested info provided in email.

Comment 12

[alice nodelman [:alice] [:anode]]

Any ETA here?

Comment 13

[Dustin J. Mitchell [:dustin] (he/him)]

I'll work on this.

Comment 14

[Dustin J. Mitchell [:dustin] (he/him)]

This change is scheduled to land this Sunday, along with bug 600980 - that will mean new performance numbers on Monday morning.

Comment 15

[Dustin J. Mitchell [:dustin] (he/him)]

done, and sync'd to build.mozilla.org.  I'll trigger more tests on 5a46d17c72ca once build.mozilla.org's back up.

Comment 16

[Dustin J. Mitchell [:dustin] (he/him)]

six runs of talos-dirty re-triggered on a09dfe6c7c19, actually, as it was the last revision to have completely run its tests before the profiles were updated.