N1QL throughput dropped by 99% on build 7.2.0-5298

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.

http://changelog.build.couchbase.com/?product=couchbase-server&fromVersion=7.2.0&fromBuild=5285&toVersion=7.2.0&toBuild=5299&f_asterixdb=off&f_build=off&f_cbas-core=off&f_cbbs=off&f_cbft=off&f_cbftx=off&f_cbgt=off&f_eventing=off&f_kv_engine=off&f_magma=off&f_n1fty=off&f_ns_server=off&f_query=on&f_testrunner=off

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.