Bug 39688 - We should check if a DB needs to be auto-vacuumed only after transactions that delete something
Summary: We should check if a DB needs to be auto-vacuumed only after transactions tha...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Dumitru Daniliuc
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-25 14:40 PDT by Dumitru Daniliuc
Modified: 2010-06-01 16:26 PDT (History)
4 users (show)

See Also:


Attachments
patch (7.77 KB, patch)
2010-05-25 15:58 PDT, Dumitru Daniliuc
dumi: commit-queue-
Details | Formatted Diff | Diff
patch (8.73 KB, patch)
2010-06-01 15:47 PDT, Dumitru Daniliuc
dglazkov: review+
dumi: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dumitru Daniliuc 2010-05-25 14:40:15 PDT
We used to check if a DB needs to be auto-vacuumed after every transaction. The check is freelist_count >= 10% * max_page_count. It turns out that getting freelist_count and max_page_count after every transaction adds a significant overhead. Once we changed the code to run this check only after transactions that have modified the database, the running times of our SELECT benchmarks have gone back to normal.

We should improve this even further: we should get freelist_count and max_page_count only after transactions that have deleted something (DELETE, DROP TABLE, etc.). This should considerably reduce the auto-vacuum-related overhead for transactions that only insert or update data. This is a heuristic: in theory, an UPDATE could replace a huge BLOB with a NULL and reduce the size of a database by >= 10%, but it seems to me that this is a very uncommon case.
Comment 1 Dumitru Daniliuc 2010-05-25 15:58:44 PDT
Created attachment 57050 [details]
patch
Comment 2 Michael Nordman 2010-05-26 13:32:29 PDT
Comment on attachment 57050 [details]
patch

Some drive by comments.

WebCore/storage/DatabaseAuthorizer.cpp:311
 +      if (moduleName != "fts2")
"fts2"... should this be "fts3"?

WebCore/storage/SQLTransaction.cpp:476
 +          m_database->incrementalVacuumIfNeeded();
This changes the order in which 'vacuumIfNeeded' and 'didCommit' is called, I pretty sure didCommit involves reexaming the size of the database file for quota tracking purposes (which is why it's only called for xactions that modify the database).

I think 'vacuumIfNeeded' should continue to be called first.

WebCore/storage/DatabaseAuthorizer.cpp:325
 +      m_hadDeletes = m_hadDeletes || allow;
x |= b is a nice shorthand
Comment 3 Dumitru Daniliuc 2010-05-26 13:34:30 PDT
> WebCore/storage/DatabaseAuthorizer.cpp:311
>  +      if (moduleName != "fts2")
> "fts2"... should this be "fts3"?

fixed and landed this in another patch.

> WebCore/storage/SQLTransaction.cpp:476
>  +          m_database->incrementalVacuumIfNeeded();
> This changes the order in which 'vacuumIfNeeded' and 'didCommit' is called, I pretty sure didCommit involves reexaming the size of the database file for quota tracking purposes (which is why it's only called for xactions that modify the database).
> 
> I think 'vacuumIfNeeded' should continue to be called first.

done.

> WebCore/storage/DatabaseAuthorizer.cpp:325
>  +      m_hadDeletes = m_hadDeletes || allow;
> x |= b is a nice shorthand

isn't |= a binary operator? i don't think there's a similar boolean operator.
Comment 4 Dumitru Daniliuc 2010-06-01 15:47:51 PDT
Created attachment 57601 [details]
patch

Same patch merged with other changes that were submitted; also, changed "m_hadDeletes = m_hadDeletes || allow" to "m_hadDeletes |= allow".
Comment 5 Dimitri Glazkov (Google) 2010-06-01 15:59:47 PDT
Comment on attachment 57601 [details]
patch

r=me, except for:

> -    return denyBasedOnTableName(tableName);
> +    bool allow = denyBasedOnTableName(tableName);
> +    m_hadDeletes |= allow;
> +    return allow;

This looks like a neat helper function.
Comment 6 Dumitru Daniliuc 2010-06-01 16:13:46 PDT
(In reply to comment #5)
> (From update of attachment 57601 [details])
> r=me, except for:
> 
> > -    return denyBasedOnTableName(tableName);
> > +    bool allow = denyBasedOnTableName(tableName);
> > +    m_hadDeletes |= allow;
> > +    return allow;
> 
> This looks like a neat helper function.

done. added updateDeletesBasedOnTableName().
Comment 7 Dumitru Daniliuc 2010-06-01 16:26:54 PDT
Landed as r60513.