docs: add spec for query caching#3217
Conversation
gdorsi
force-pushed
the
feat/resolve-query-cache
branch
from
36b1716 to
d99c2ac
Compare
gdorsi
force-pushed
the
feat/resolve-query-cache
branch
from
d99c2ac to
9a68cd4
Compare
gdorsi
force-pushed
the
feat/resolve-query-cache
branch
from
9a68cd4 to
91fc8d1
Compare
gdorsi
force-pushed
the
feat/resolve-query-cache
branch
from
dcf9dae to
806346f
Compare
| this.unstable_branch, | ||
| undefined, // calleer stack | ||
| this.cacheable, // propagate cacheable flag to child | ||
| this.cacheKey // propagate cache key to child |
There was a problem hiding this comment.
How's the parent scope's cache key used by the child scope?
There was a problem hiding this comment.
If provided, the child uses that one as cacheKey.
| } | ||
|
|
||
| export interface DBTransactionInterfaceAsync { | ||
| updateCoValue( |
There was a problem hiding this comment.
I understand this spec is not focused on how this will be implemented, but it'd be nice to have a bit more detail about how we plan to update the cache. I guess there's a tradeoff here between cache granularity, how many DB read/writes we perform on each load/update operation and amount of storage used by the caching layer, and I'm not sure where we're aiming at
There was a problem hiding this comment.
Yeah, you are right, I wanted to give this some more thinking before writing down some guidance and then my focus shifted elsewere.
The first thing I was thinking to try is to index CoValueRow.cacheKeys so we can get all the coValues related to a given cacheKey.
Perf wise it probably won't give us much, because the real "cost" lies on gathering the transactions, so we need to deal with that as well.
On the tx we could do the same as the CoValueRow and simply add a cacheKeys list in every single transaction, or figure out a way to do compaction of the tx rows.
We could go with a "append first" approach plus background compaction in a similar way I've done for the delete operation.
My intuition tells me that for the tx we probably need compaction, because managing the cacheKeys updates on the transactions store might be too much.
Also for compaction we can try to reduce the I/O by applying gzip compression on the logs and see if it helps with performance or not.
2 participants
No description provided.