fixed slow query on normalized table; still 10x slower than current .map files
This commit is contained in:
parent
66b8b9c094
commit
3e86d35e84
1 changed files with 7 additions and 0 deletions
|
@ -67,6 +67,7 @@ CachedKey
|
||||||
AssociatedFiles
|
AssociatedFiles
|
||||||
keyId CachedKeyId Eq
|
keyId CachedKeyId Eq
|
||||||
associatedFile FilePath
|
associatedFile FilePath
|
||||||
|
KeyIdIndex keyId associatedFile
|
||||||
deriving Show
|
deriving Show
|
||||||
|
|
||||||
CachedMetaField
|
CachedMetaField
|
||||||
|
@ -86,6 +87,12 @@ LastFscked
|
||||||
With this, running 1000 joins to get the associated files of 1000
|
With this, running 1000 joins to get the associated files of 1000
|
||||||
Keys took 5.6s with warm cache. (When done in the same `runSqlite` call.) Ouch!
|
Keys took 5.6s with warm cache. (When done in the same `runSqlite` call.) Ouch!
|
||||||
|
|
||||||
|
Update: This performance was fixed by adding `KeyIdOutdex keyId associatedFile`,
|
||||||
|
which adds a uniqueness constraint on the tuple of key and associatedFile.
|
||||||
|
With this, 1000 queries takes 0.406s. Note that persistent is probably not
|
||||||
|
actually doing a join at the SQL level, so this could be sped up using
|
||||||
|
eg, esquelito.
|
||||||
|
|
||||||
Compare the above with 1000 calls to `associatedFiles`, which is approximately
|
Compare the above with 1000 calls to `associatedFiles`, which is approximately
|
||||||
as fast as just opening and reading 1000 files, so will take well under
|
as fast as just opening and reading 1000 files, so will take well under
|
||||||
0.05s with a **cold** cache.
|
0.05s with a **cold** cache.
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue