faster associated file replacement with upsert
authorJoey Hess <joeyh@joeyh.name>
Tue, 8 Jun 2021 11:09:07 +0000 (07:09 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 8 Jun 2021 11:53:36 +0000 (07:53 -0400)
commitc831a562f550e6ff93e081f555eced3a8a0d524f
treea44d984e82f93610c84f2fb6221018b440fda803
parente9a8b48a52392c80991afb19f1d52ed58c7dd843
faster associated file replacement with upsert

Rather than first deleting and then inserting, upsert lets the key
associated with a file be updated in place.

Benchmarked with 100,000 files, and an empty keys database, running
reconcileStaged. It improved from 47 seconds to 34 seconds.
So this got reconcileStaged to be as fast as scanAssociatedFiles,
or faster -- scanAssociatedFiles benchmarks at 37 seconds.

(Also checked for other users of deleteWhere that could be sped up by
upsert. There are a couple, but they are not in performance critical
code paths, eg recordExportTreeCurrent is only run once per tree
export.)

I would have liked to rename FileKeyIndex to FileKeyUnique since it is
being used as a uniqueness constraint now, not just to get an index.
But, that gets converted into part of the SQL schema, and the name
is used by the upsert, so it can't be changed.

Sponsored-by: Dartmouth College's Datalad project
Database/Keys/SQL.hs