[DOCS-8151] Definition of "listQueryShapes" does not match other definitions of query caching Created: 22/Jun/16  Updated: 11/Jan/17  Resolved: 08/Jul/16

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: mongodb-3.2
Fix Version/s: 01112017-cleanup

Type: Bug Priority: Major - P3
Reporter: Steven Hand Assignee: Ravind Kumar (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 7 years, 31 weeks, 5 days ago

 Description   

The definition of the "PlanCache.listQueryShapes()" states:

The query optimizer only caches the plans for those query shapes that can have more than one viable plan.

Certainly, this method only returns query shapes for those queries than can use either of two indexes, (e.g. {a:1} and {a:1, b:1})

But the definition of when query plans are cached is different in SERVER-15225, which states:

The query optimizer caches plans for each query shape and reuses these plans for a time.

Does the query planner cache all past query plans or only those that have two viable plan?

I suspect that the behavior of the listQueryShapes() method is that it does not return all cache query plans.



 Comments   
Comment by Steven Hand [ 08/Jul/16 ]

david.storch and ravind.kumar,

Let's close this ticket.

Comment by Ravind Kumar (Inactive) [ 06/Jul/16 ]

steven.hand: If there are no objections, I'd like to close this ticket as the existing documentation is correct as it stands.

Comment by David Storch [ 23/Jun/16 ]

steven.hand, it is indeed the case that for queries which have only one solution, that the planner must do the work to construct the plan each time. Somewhat counterintuitively, I don't think that we would be saving much (if any) work by caching single-solution queries. The main benefit of the cache is that the system can skip plan selection; since MongoDB uses an empirical strategy for plan ranking, the plan selection phase actually invokes the query execution machinery, which can be expensive. When the winning plan is cached, the entire plan selection phase can be skipped, which can result in large latency savings.

If there is just a single query plan, then the plan selection phase can also be skipped. The process of reconstituting a plan based on the plan cache entry is actually quite similar to the process of planning a single-solution query without the cache. Therefore, there is not necessarily a large performance benefit associated with caching single-solution queries. That said, we have an open ticket tracking precisely this work: SERVER-13341, whose title "Cache single solution query plans". It is quite possible that there would be a small performance benefit associated with this change, in exchange for more data stored in the plan cache. More importantly, I think this would make the plan cache introspection commands easier to use and reason about.

Comment by Steven Hand [ 23/Jun/16 ]

david.storch, would it be correct to say that we are constantly re-planning queries that have one have one solution (like only have one index containing the field being queried). If so, wouldn't the constant re-planning of queries rise to be a significant portion of the execution time for all queries of a given shape in cases of high query load on a given collection?

Comment by Steven Hand [ 23/Jun/16 ]

ravind.kumar, as I understand it, we set "internalQueryCacheReplanningEnabled:true" by default starting in 3.0.7, as per SERVER-20139

Comment by David Storch [ 22/Jun/16 ]

Currently, we only cache a plan for query shapes that have at least two query solutions. If the only solution is a collection scan, or there is only a single indexed plan available to answer the query, then no cache entry will be created. So the documentation for PlanCache.listQueryShapes() is correct. SERVER-15225 should probably be clarified, as is does make it sound like a cache entry is always generated. Thanks steven.hand for pointing out this inconsistency!

Generated at Thu Feb 08 07:55:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.