Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
7.2.0
-
Untriaged
-
0
-
Yes
Description
We are seeing N1QL throughput dropped by 99% on build 7.2.0-5298. The regression happened in most of the throughput tests across the board.
These are query changes between 7.2.0-5285 and 7.2.-5298.
CHANGELOG for query:
Commit: 8abd741db78970f27aa1b3c34ce14798bb2f0ea9 in build: couchbase-server-7.2.0-5297
MB-56318 Ensure bucket updater is stopped on bucket close
Have streaming function directly respond with the need to exit the
updater rather than indicating this via the StopUpdater function. This
will ensure that even if a new updater has been kicked off, the existing
updater will exit.
Ensure bucket close stops updater and that updater is stopped when pool
is closed.
Don't use loadNamespace as it duplicates the namespace and buckets
(which can lead to updaters leaking).
Also enhanced bucket updater messages so we can more easily tie messages
to an individual bucket object instance.
Commit: ade030ebf64265cd1c77771e7ed823c3387f2c45 in build: couchbase-server-7.2.0-5295
MB-56333 Add buffer to runQueue
BP of MB 56276 to 7.2.0.
Commit: 050df6c912f8060546f3edbfa72194dc95f554d3 in build: couchbase-server-7.2.0-5294
MB-56306: go mod tidy
Commit: 68dd174c0f5188b2c9aaa426e0ee3a2717b558a2 in build: couchbase-server-7.2.0-5290
MB-56284 Detect and mark "constant" filters in subterms of OR-clause
The issue was first identified in 7.0.5 (MB-53793) and not in
later code lines since we handle OR-clause differently in later
codelines. However, we've identified issues with OR-clause
handling and fix the issues with MB-56039, after which the
symptom of MB-53793 now shows in 7.2.0 and 7.5.0.
The problematic query has an OR-clause like:
(c2 = 6 AND IFMISSINGORNULL($qp1, "") != "") OR (IFMISSINGORNULL($qp1, "") == "")
the issue is we have part of the predicate in each arm of the
OR-clause as "constant" predicate, i.e. it does not depend on
the document, rather it only depends on a named parameter.
Such subclauses causes issues when sarging index keys since
they don't generate any index spans but they are not detected
by the "covering" test we currently use to check whether the
index spans are "exact". The issue is somewhat similar to
MB-50071 except the "constant" predicate in this case is part
of subterms of an OR-clause and thus not detected by the fix
for MB-50071.
To fix this issue, we need to add a mechanism to detect such
"constant" predicates in subterms of an OR-clause. This is
built on top of the fix for MB-42474, and we check in case of
OR-clause whether any subterm of the OR has such "contant"
predicates, if so, mark an extra flag to prevent index
aggregation pushdown.
An extra modification is also done for classifying expressions,
such that when we have an OR clause under and AND, we do the
necessary OR-clause processing to remove any constant subterms.