Verify DeleteCachId and/or DeleteAllCacheEntries for performance bottlenecks
Categories
(Core :: Storage: Cache API, task)
Tracking
()
People
(Reporter: jstutte, Unassigned)
References
Details
From bug 1951283 comment 27 it seems that there is some room for improvement here. It might just be a missing index, or we might be actually doing more than needed.
There is one long execution of DeleteCacheId in that profile that puzzles me a bit (which was not supposed to be changed by these patches, fwiw). At least from the function names I do not really get why
DeleteCacheIdshould callDeleteAllCacheEntriesat all and there I find this interesting comment which hints that there is some known problem there, although from the profile it seems, that the execution of the statement itself is slow, not reading its results?
|
Reporter | |
Comment 1•1 year ago
•
|
||
At least from the function names I do not really get why DeleteCacheId should call DeleteAllCacheEntries at all
OK, reading a bit more in the source clarified to me the difference between the CacheId referring to the entire named cache and a single entry. Indeed the testcase from bug 1951283 does a caches.delete('empty-string-cache'); which then is supposed to delete all entries that belong to that cache.
It seems we have two levels of nesting across three tables where we do ON DELETE CASCADE. This is most likely just an expensive operation. I wonder if we could just store the cache id on all dependent tables and do delete them starting from the leafs of the dependency tree, avoiding the cascade delete all together, in addition to the possible improvement already described here.
Description
•