[SERVER-53719] Skip opening storage snapshot for fast count in order to regain 10-15% performance Created: 12/Jan/21 Updated: 14/Oct/21 Resolved: 14/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | execution-product-sync, pm-1820 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Execution Team 2021-10-18 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 15 | ||||||||
| Description |
|
With LFR work, we can now access the CollectionCatalog to fetch a safe-to-use Collection shared_ptr without any lock helper. Switching the count cmd generally over to LFR has introduced explicitly opening storage snapshots, rather than implicitly in the storage integration layer when a read is actually requested. Since fast count doesn't access the storage layer, LFR early opening of storage snapshots is slowing down the operation significantly. The storage snapshot is opened via the LFR lock helper, which should be removed. |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 01/Oct/21 ] |
|
So a little more complicated than I realized. Fast count, which goes to the Collection's in-mem count, and regular count that starts a query, are on the same code path. So I think we just need to distinguish between user requests that will go to Collection and those that will perform a query to get count results. Looking into that.. |
| Comment by Dianna Hohensee (Inactive) [ 17/Aug/21 ] |
|
I'd like to reconsider this for scheduling, as a quick win. I don't think we need to fiddle with AutoGet helper implementation, I think we just need to remove the AutoGet and fetch a CollectionPtr shared_ptr, which is simple? |
| Comment by Geert Bosch [ 25/May/21 ] |
|
Should be unlinked. |
| Comment by Dianna Hohensee (Inactive) [ 25/May/21 ] |
|
I don't know the reason. WT's changes to provide count (WT-7408) could cause us to change the fast count code, but that would be a subsequent SERVER ticket, not a WT ticket. I'm also unaware how that might change locking requirements. geert.bosch, any context for this dependency, or should it be unlinked? |
| Comment by Eric Milkie [ 25/May/21 ] |
|
Why does this work depend on WT-7408? |