[SERVER-59659] Investigate allowing the change stream oplog query to run using the pipeline collation Created: 28/Aug/21 Updated: 06/Mar/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Justin Seyster | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Change streams have always prevented a user-defined collation from being applied to the filter pushed down into the oplog, primarily so that a case-insensitive collation cannot cause a single-collection stream to return events from multiple similarly-named collections (see This became an issue during PM-1942, since we are now rewriting user filters into the oplog, and the user may have specified a collation for their $match filters. We therefore chose, in However, in practice the changes inĀ It may therefore now be safe to allow the oplog query to have an arbitrary collation. |
| Comments |
| Comment by Bernard Gorman [ 03/Oct/21 ] |
|
Note that one consideration here is that we would have to prevent any of our oplog rewrites from converting a user-defined string equality filter into a regex, since that would cause the predicate to incorrectly ignore the collation. For instance, we currently rewrite some string-equality predicates on field 'ns' into a regex here. While this isn't critical - very few people are likely to run change streams with a non-simple collation - it would be nice to get rid of this restriction and the temporarilyChangeCollator "workaround" along with it, since this mechanism only exists because of change streams and is not used anywhere else in the server. As a (less desirable) alternative, if it is not feasible to simply allow the user collation to be applied to the oplog query, we could selectively permit predicates on collation-agnostic fields as outlined in I'd suggest placing this ticket in the QO Quick Wins bucket. |