Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Speed up iPhoto '09 by vacuuming its databases' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Speed up iPhoto '09 by vacuuming its databases
Authored by: mal0rd on Mar 02, '09 10:44:05PM
I wouldn't recommend this. According to SQLite's documentation:
The VACUUM command may change the ROWIDs of entries in tables that do not have an explicit INTEGER PRIMARY KEY.
Who knows if Apple uses the implicit ROWIDs? It's bad practice, but not illegal. And if they do, this command probably corrupts your data.

[ Reply to This | # ]
can this be investigated?
Authored by: bcamp1973 on Mar 03, '09 12:04:50PM

how might one check this? my iphoto 09's performance is crap. i'd really like to run this...



[ Reply to This | # ]
can this be investigated?
Authored by: palahala on Mar 05, '09 06:12:10AM

I don't use iPhoto, but an example to show some Mozilla Firefox database information (commands like .tables and .schema moz_places show information about the database; the indented text are the responses for this example):

cd ~/Library/Application Support/Firefox/Profiles/*.default/ 

sqlite3 places.sqlite

    SQLite version 3.4.0
    Enter ".help" for instructions

sqlite> .tables

    moz_anno_attributes  moz_favicons         moz_keywords       
    moz_annos            moz_historyvisits    moz_places         
    moz_bookmarks        moz_inputhistory   
    moz_bookmarks_roots  moz_items_annos    

sqlite> .schema moz_places

    CREATE TABLE moz_places (id INTEGER PRIMARY KEY, url LONGVARCHAR,
        title LONGVARCHAR, rev_host LONGVARCHAR, visit_count INTEGER DEFAULT 0,
        hidden INTEGER DEFAULT 0 NOT NULL, typed INTEGER DEFAULT 0 NOT NULL,
        favicon_id INTEGER, frecency INTEGER DEFAULT -1 NOT NULL);
    CREATE INDEX moz_places_faviconindex ON moz_places (favicon_id);
    CREATE INDEX moz_places_frecencyindex ON moz_places (frecency);
    CREATE INDEX moz_places_hostindex ON moz_places (rev_host);
    CREATE UNIQUE INDEX moz_places_url_uniqueindex ON moz_places (url);
    CREATE INDEX moz_places_visitcount ON moz_places (visit_count);

sqlite> .exit
Something like the example above can give you an idea of the table structure used in iPhoto as well. Above, the id INTEGER PRIMARY KEY indicates that Firefox would not suffer from this ROWID problem, for that specific table moz_places. Checking all iPhoto tables like this, you might get an idea about the iPhoto database.

[ Reply to This | # ]
Speed up iPhoto '09 by vacuuming its databases
Authored by: wjv on Mar 31, '09 09:37:15AM

That should not to be a problem, since an implicit ROWID ought not to be referenced by any other table. (In essence, it's an "internal" value for SQLite.)

Just MHO, of course. Take all due precautions before VACUUMing your databases.



[ Reply to This | # ]