SQLite: Don't bill for internal queries.

[kentonv]

We bill for:

• SQL queries issued via the JavaScript SQL API.
• DO old-style key/value storage operations.

Anything else, we assume is an internal query, and not billed.

[shrima-cf]

LGTM

[jclee]

(I guess the stmtCountKeys prepared statement doesn't use this regulator yet, so would be excluded from stats, but not sure if that query represents notable overhead.)

[kentonv]

Ah good catch, probably should fix that.

[jclee]

Nice... When I was thinking about how to implement something similar, I was considering adding a "reportingId" value to queries, which could then be passed as an additional parameter to addQueryStats()... That might have the advantage of allowing us to separately track both system query overhead (maybe for internal metrics?) and user query overhead. But not sure if we need that, and if not, this approach seems simpler and more performant.

I guess I also don't know enough about the query stats recording to know if running "ROLLBACK" as a system query -- after running some user queries -- results in significant overhead that we'd want included in user metrics. But maybe that's not a big deal, as long as the stats of the initial execution get recorded and are roughly proportional to what the rollback metrics would be.

[kentonv]

I guess I also don't know enough about the query stats recording to know if running "ROLLBACK" as a system query -- after running some user queries -- results in significant overhead that we'd want included in user metrics.

The overhead of ROLLBACK is pretty minimal, the WAL just gets truncated back to an earlier point. In fact, any writes that end up rolled back never even leave the local machine, so you could argue a rollback should actually roll back the billing counters! But that would be complicated to implement and awkward to explain.