[SERVER-77738] [CQF] Audit logging in Bonsai Created: 02/Jun/23 Updated: 06/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Hana Pearlman | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Optimization
|
| Participants: |
| Description |
|
We should make sure all Bonsai-specific logs are behind a reasonable (high enough) log level. We should introduce a log component (or sub-component under "query") for Bonsai. This should include deciding what to do with internalCascadesOptimizerStdCoutDebugOutput. Can these prints just turn into logs under a higher verbosity level? |
| Comments |
| Comment by Ben Shteinfeld [ 20/Jul/23 ] |
|
I think there is another axis of logging at the OptPhaseManager level, https://github.com/10gen/mongo/blob/master/src/mongo/db/query/optimizer/defs.cpp#L142-L144. These logs are used in unit tests for logical and physical rewrites. Are these included as part of this audit? If so, I'd suggest improving the output for tracing optimizeGroup, for example, the output for when branch and bound rejects a rewrite simply says "failed optimization". |