On 5 Mar '08, at 9:15 AM, I. Savant wrote:
Okay, well that sucks. So now the question is this: does Core Data
implicitly run VACUUM? If so, when? How often? Unfortunately googling
and archive-searching did not produce any obvious answers to this
particular question. My guess is that the
I don't know the answer; but it probably doesn't vacuum at every save.
Vacuuming can be quite slow if the database is at all large,
especially if there's already a lot of disk I/O going on. (The vacuum
algorithm has to read and write every page of the database.)
That certainly makes
... so that's fine, but SQLite's documentation says of auto_vacuum:
When the auto-vacuum flag is 1 (full), the freelist pages are moved
to the end of the file and the file is truncated to remove the
freelist pages at every commit. Note, however, that auto-vacuum only
truncates the freelist
If you have any performance data showing problems with internal db
fragmentation (i.e. sqlite3 dbname 'vacuum' fixes it, but cp
doesn't), we'd love to hear about it.
Thanks, Ben, for this informative response. So what you're saying,
in summary is:
1 - Vacuuming on every save is
On 5 Mar '08, at 3:49 PM, I. Savant wrote:
To that, I pose another question: Why, then, does it make such a
huge difference when I run the vacuum command against Mail's
database? After just a month of usage, Mail seems sluggish when
switching between various folders, but once I run the
Mail [which does not use CoreData, btw] might not have enabled
auto_vacuum. IIRC, there were bugs in auto_vacuum in the version of
sqlite that shipped in Tiger.
I thought I remembered reading that Mail does not use Core Data. It
does, however, use SQLite and auto_vacuum is a problem
If you have any performance data showing problems with internal db
fragmentation (i.e. sqlite3 dbname 'vacuum' fixes it, but cp
doesn't), we'd love to hear about it.
Thanks, Ben, for this informative response. So what you're saying,
in summary is:
1 - Vacuuming on every save is
