[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:
Depends
Related
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?

Generated at Thu Feb 08 05:31:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.