{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":30624483,"defaultBranch":"master","name":"query","ownerLogin":"couchbase","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2015-02-11T01:37:21.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/605755?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1712099941.0","currentOid":""},"activityList":{"items":[{"before":"b24aa3e5754676b864f295814b5f1f1a53df9f18","after":"3f6ae16c52ceb9e3b281306c01080f43a8a84cf6","ref":"refs/heads/master","pushedAt":"2024-06-07T18:52:08.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"Merge remote-tracking branch 'origin/trinity'\n\nChange-Id: Iaea0541fa829041c5885e9ad23f29de227d1396e","shortMessageHtmlLink":"Merge remote-tracking branch 'origin/trinity'"}},{"before":"14bb430fdf38f083a1fa2410c6a38873bc40f6f8","after":"5a9e560c49a3c1bb4eb6c7070b18e5f498b9b963","ref":"refs/heads/trinity","pushedAt":"2024-06-07T18:46:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62216 Handle OFFSET properly in early order\n\nThe issue in this defect is with the handling of OFFSET in\nearly order when the order also has a partialSortTermCount,\ni.e. the index provides part of the total order.\n\nThe current code assumes that when partialSortTermCount is\npresent, then the OFFSET is handled by the SORT operator.\nThis is true for the \"regular\" SORT operator (typically at\nthe end of the plan), but not always true for early order,\nsince in case the index scan does not have EXACTSPANS we\ncannot push the OFFSET to the early SORT operator, in\nwhich case the OFFSET cannot be handled by early order.\n\nTo fix this we need to remove the assumption for\npartialSortTermCount in early order, and just let existing\nlogic takes care of determining whether OFFSET is already\nhandled (which is based on this.offset == nil).\n\nChange-Id: I843849aa5bb91276fe4a9f1c4ab0d14587a5d586\nReviewed-on: https://review.couchbase.org/c/query/+/211084\nReviewed-by: Sitaram Vemulapalli \nTested-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker","shortMessageHtmlLink":"MB-62216 Handle OFFSET properly in early order"}},{"before":"cb5c27953a24f53dfe1e3760ba917730f71720a0","after":"b24aa3e5754676b864f295814b5f1f1a53df9f18","ref":"refs/heads/master","pushedAt":"2024-06-07T01:05:21.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60680 Skip vector index key for UPDATE STATISTICS\n\nFor now during UPDATE STATISTICS for INDEX, skip vector index\nkeys.\n\nAlso moved a couple of utility functions from planner to\ndatastore so we can use it in UPDATE STATISTICS as well.\n\nChange-Id: I48c75496aeb54980c33d22423d28b0aeea79586a\nReviewed-on: https://review.couchbase.org/c/query/+/210999\nTested-by: Bingjie Miao \nReviewed-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-60680 Skip vector index key for UPDATE STATISTICS"}},{"before":"ed55b431cc8eca7854b5f2328d1744425f95b260","after":"cb5c27953a24f53dfe1e3760ba917730f71720a0","ref":"refs/heads/master","pushedAt":"2024-06-06T21:20:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62157 Change builder flags to uint64 to make room for new flags\n\nChange-Id: I98c5b67fc5f28068fa997f92fa22fa5a356cc411\nReviewed-on: https://review.couchbase.org/c/query/+/210993\nReviewed-by: Sitaram Vemulapalli \nTested-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-62157 Change builder flags to uint64 to make room for new flags"}},{"before":"32e3d77f9400f9e60b56ae4cdef2f0914a97a391","after":"ed55b431cc8eca7854b5f2328d1744425f95b260","ref":"refs/heads/master","pushedAt":"2024-06-06T20:43:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62157 Improve handling of cover transformation for SubqueryTerm\n\nThis is a more thorough fix of the issue.\n\nIn the problematic query we have a SubqueryTerm on the right-hand\nside of a join, and there is an ANY predicate inside the subquery.\nThe subquery can be covered with an array index. The issue is\nthat the SubqueryTerm is planned multiple times during the planning\nprocess. This is more obvious with join enumeration, but could\nhappen even if CBO is turned off.\n\nWe now check and delay cover transformation for a SubqueryTerm,\nunder the following conditions:\n\n - during join enumeration, where we know the SubqueryTerm can\n be planned multiple times\n - when it is used on the inner side of a nested-loop join,\n where we will create an ExpressionScan on top of the subquery\n and the subquery will be planned at execution time\n\nNote that hash join is not an issue since in case of hash join,\nthe subquery plan is embedded in the main query plan, i.e. no\nseparate planning/execution of the subquery at run time.\n\nThe fix includes the following:\n\n - new builder flag to mark that a SubqueryTerm is used as\n inner of nested loop join\n - new map in the builder to save a subquery's plan, with\n algebra.Subselect as the key\n - when planning a subselect, check whether cover transformation\n should be performed, and if not, save the subquery plan in\n the map instead\n - new builder flag to indicate the statement is not to be\n executed, which includes EXPLAIN, ADVISE, and EXPLAIN FUNCTION\n - in case of non-execution, at the top of the Select, go\n through the generated plan and find situations where an\n ExpressionScan covers a subquery, and perform cover\n transformation for such subqueries.\n - otherwise (where actual execution happens), no need to\n do so, and let the planning at runtime handles cover\n transformation (since at that time it'll not be seen as\n a subquery under a join, it is a standalone subquery\n and cover transformation will happen).\n - if doing join enumeration, when the final plan is chosen,\n in addition to existing logic to perform cover transformation\n on the final plan, also check whether any saved subquery plan\n is present, and if so, perform cover transformation in case\n of non-execution.\n - during join enumeration, if execution will happen, first\n find and remove subqueries under inner of a nested-loop\n join and remove it from the saved plans (leave it to run time)\n - note that for join enumeration we use a copy of the builder,\n i.e. the saved plans for join enumeration is separate from\n the saved plans if join enumeration is not done. As a\n result all saved plans during join enumeration will need to\n be handled by join enumeration as well.\n - need to move the logic for doing cover transformation for\n the final plan out of query-ee and into query, since it is\n now required even if join enumeration is not in play\n - the (moved) logic for handling cover transformation for a\n plan is also enhanced to handle more operators, since now\n it needs to handle the whole plan from a subselect.\n - modifications to the Builder and Optimizer interfaces in\n planner to account for the moved logic.\n - added a new Subselects() function to algebra.Result interface\n to gather all Subselects under a Select.\n - other various modifications to plan operators (mostly adding\n functions to replace an expression if cover transformation\n is done).\n\nChange-Id: I0b09f3cef26083f54673ce57b09baa3e0fcde9d3\nReviewed-on: https://review.couchbase.org/c/query/+/210989\nTested-by: Sitaram Vemulapalli \nReviewed-by: Donald Haggart \nReviewed-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-62157 Improve handling of cover transformation for SubqueryTerm"}},{"before":"4f9bb6792a9207be007d281a8e0b656d93ba184f","after":"14bb430fdf38f083a1fa2410c6a38873bc40f6f8","ref":"refs/heads/trinity","pushedAt":"2024-06-06T14:05:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62167: go mod tidy\n\nChange-Id: Ic6418d448603e1ab90a33052204bd33b1da29905\nReviewed-on: https://review.couchbase.org/c/query/+/210977\nWell-Formed: Restriction Checker\nReviewed-by: Abhi Dangeti \nTested-by: Abhi Dangeti ","shortMessageHtmlLink":"MB-62167: go mod tidy"}},{"before":"a662fa4ad5f4b86b40d09b1e31cdc2e40ae1f1d9","after":"32e3d77f9400f9e60b56ae4cdef2f0914a97a391","ref":"refs/heads/master","pushedAt":"2024-06-06T02:48:08.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"Merge remote-tracking branch 'origin/trinity'\n\nChange-Id: Iaa944f3a61fd4e089cfe017db5ce171edccf929c","shortMessageHtmlLink":"Merge remote-tracking branch 'origin/trinity'"}},{"before":"2bf948e2d530f3920e62802cc7d9ce4b0709dcb0","after":"4f9bb6792a9207be007d281a8e0b656d93ba184f","ref":"refs/heads/trinity","pushedAt":"2024-06-05T22:54:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62157 Ensure a covered ANY predicate remains covered ...\n ... after covering transformation\n\nIn the problematic query we have a SubqueryTerm on the right-hand\nside of a join, and there is an ANY predicate inside the subquery.\nThe subquery can be covered with an array index. The issue is\nthat the SubqueryTerm is planned multiple times during the planning\nprocess. This is more obvious with join enumeration, but could\nhappen even if CBO is turned off.\n\nThe issue is that the first time the SubqueryTerm is planned, we\ndetermine that covering is possible, and then proceed with cover\ntransformation for the subquery AST tree. Subsequent planning of\nthe SubqueryTerm now sees the transformed \"cover\" expression, and\nfor most expressions this works fine, i.e. does not interfere with\ncovering determination (since we just get the embedded expression\nfrom the \"cover\" expression, see CoveredBy() function for Cover\nexpression, in expression/index_cover.go). However for ANY\npredicate we use a special process (through filter covers) for\ncovering purpose, and this process currently does not handle\n\"cover\" expressions, as a result all subsequent planning of the\nSubqueryTerm incorrectly determines that covering cannot be done.\n\nWhile this process is somewhat flawed (we should probably not\nperform covering transformation the first time the SubqueryTerm\nis planned), however to change this involves fairly complicated\ninfrastructual change and is probably not desiable for 7.6 at\nthis point. Instead a simple change to allow \"cover\" expression\nto work for ANY predicate when determining filter covers is\ndone to allow proper determination of covering (with ANY\npredicate) if the expression has already gone through cover\ntransformation.\n\nChange-Id: Ib0c01a1250071150636fb0aa3a5f8dca91d48d93\nReviewed-on: https://review.couchbase.org/c/query/+/210933\nWell-Formed: Restriction Checker\nTested-by: Sitaram Vemulapalli \nReviewed-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-62157 Ensure a covered ANY predicate remains covered ..."}},{"before":"3b58cc206cd05c5a7451649d33aa9b77781bdffd","after":"a662fa4ad5f4b86b40d09b1e31cdc2e40ae1f1d9","ref":"refs/heads/master","pushedAt":"2024-06-04T11:35:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60360 Reduce size of annotatedValue\n\nMETA has a fixed list of well defined fields. Replacing a\nmap[string]interface{} with a simple structure saves a noticeable\nportion of memory. This change naturally requires an API change to\ninteract with it. Mimicking the existing get/set for fields rather than\nindividual get/set methods for structure members reduces the overall API\nchanges. (The API changes mean meta logic is contained within the\nannotated value.)\n\nMost attachments are well-known names too, so these at least should be\nconstants rather than literals where used. Replacing the\nmap[string]interface{} with a map[int16]interface{} still leaves us with\na reasonable number of attachments (I'd argue map[byte]interface{}\nwould be enough and would be better still) and saves us a lot too.\n\nThe special case though is that we do - for WINDOW and ORDER BY - label\nattachments with non-well-known values. To accommodate this a well\nknown attachment is added with an array of strings identifying the\nfollowing indices. Lookup is a linear search through this array: in\nmost cases it will not be that long & we're trying to avoid memory\nwasting maps. As documents may have differing sets of attachments prior\nto arriving at a WINDOW or ORDER BY, we can't pre-compute this list.\n\nChange-Id: Id74a01dc12baf1efd41d2320e1d33530b3662df7\nReviewed-on: https://review.couchbase.org/c/query/+/206489\nTested-by: Donald Haggart \nReviewed-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-60360 Reduce size of annotatedValue"}},{"before":"944f42ac5be6a1a6a1dc51d085ee16f4ebee7814","after":"2bf948e2d530f3920e62802cc7d9ce4b0709dcb0","ref":"refs/heads/trinity","pushedAt":"2024-06-03T18:32:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60943: go mod tidy\n\nChange-Id: Id834714fdfd1a81c8c12de0d9951237b1b034e3c\nReviewed-on: https://review.couchbase.org/c/query/+/210821\nReviewed-by: Abhi Dangeti \nWell-Formed: Restriction Checker\nTested-by: Abhi Dangeti ","shortMessageHtmlLink":"MB-60943: go mod tidy"}},{"before":"613b10f958daec29172510c7183b08d29e11aec3","after":"3b58cc206cd05c5a7451649d33aa9b77781bdffd","ref":"refs/heads/master","pushedAt":"2024-05-29T17:32:25.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"Merge remote-tracking branch 'origin/trinity'\n\nChange-Id: I530a29342dbc4da1876f99ef83e07583071ca347","shortMessageHtmlLink":"Merge remote-tracking branch 'origin/trinity'"}},{"before":"08e85bd9c3a38320e0ea809537d4268ca72c4ed1","after":"944f42ac5be6a1a6a1dc51d085ee16f4ebee7814","ref":"refs/heads/trinity","pushedAt":"2024-05-29T17:15:00.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62073 Forward port fix\n\nAlthough 7.6 behaves differently, the fix is still valid in\n7.6 as well.\n\nIn 7.6, we did not eliminate the 3rd index (without proper\ncost) since the index has an index filter (which was not\npresent in 7.2, due to fix of MB-56616 in 7.6 only). Thus\nwe generate an intersect scan with 3 indexes in 7.6, but\nsince one of the indexes does not have proper cost, we\ndo perform early termination at runtime instead of waiting\nfor all index scans to finish, i.e. the slow performance\nobserved in 7.2 does not occur in 7.6. However the fix\nin 7.2 is still valid.\n\nThe part about generating index spans is also different\nin 7.6 vs 7.2. In 7.6 we generate index spans early on\nand thus we could calculate cost even when shortest is\nfalse.\n\nChange-Id: If4293f78cf6cf93626314487b681dbe491278695\nReviewed-on: https://review.couchbase.org/c/query/+/210653\nReviewed-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker\nTested-by: Sitaram Vemulapalli \nReviewed-on: https://review.couchbase.org/c/query/+/210661","shortMessageHtmlLink":"MB-62073 Forward port fix"}},{"before":"b30c5b9a8a8780252698480e24c4d085864521b7","after":"70943c47a4197692f1c714381918ef7ad42cf3bd","ref":"refs/heads/neo","pushedAt":"2024-05-29T16:24:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62059 Proper generation of array index key in index advisor\n\nThe index advisor generates array index keys by evaluating the\nANY clause used in the query. For this bug, a non-traditiional\nANY clause is used:\n\n ANY i IN [1,2] SATISFIES i = id END\n\nnote that teh binding is referencing a constant array construct.\nThe index advisor is not handling this form well and generates\nan invalid syntax for the array index key.\n\nSeveral changes are made to address this issue:\n\n - add a \"phase\" when gathering array index construct, such\n that we can differentiate between the \"binding\" and the\n \"satisfies\" clauses of the ANY expression\n - after gathering from the bindings, if there is no\n \"indexName\" generated, i.e. the binding is not referring\n to the source keyspace, then bail out\n - when handling constants, only return the constant\n expression if the phase is in \"satisfies\", i.e. ignore\n the constants if handling \"bindings\"\n\nAfter these changes, the index advisor now generates a\nmessage indicating no index recommendation is available.\n\nChange-Id: I82413d65dce32a0230a95f5668d05831b3edd6d1\nReviewed-on: https://review.couchbase.org/c/query/+/210612\nReviewed-by: Sitaram Vemulapalli \nTested-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker\nReviewed-on: https://review.couchbase.org/c/query/+/210656","shortMessageHtmlLink":"MB-62059 Proper generation of array index key in index advisor"}},{"before":"fe1182d5129553684725c7f9ae16ce604c5e9a96","after":"b30c5b9a8a8780252698480e24c4d085864521b7","ref":"refs/heads/neo","pushedAt":"2024-05-29T15:59:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62073 Allow CBO to choose intersect scan ...\n ... if an index without proper cost has been eliminated\n\nWhen CBO is in effect, during index selection we calculate a cost\nfor each sargable index in order to choose the best index path.\nIf one (or more) of the sargable index(es) cannot be properly\ncosted (e.g. lack of appropriate statistics, or a bug/deficiency\nin the code), then we turn CBO off. In this bug what happened\nwas that there are 3 sargable indexes, 2 of which have proper\ncosts but 1 does not. We turned CBO off (in the function) and\nused rules to eliminate the index without proper cost. At the\nend we generate an intersect scan with the two remaining indexes.\nThe problem is that the two indexes both have proper cost, and\nat runtime we have a rule that says if the intersect scan is\nchosen by cost (indicated by available cost for the intersect\nscan), then we don't do early termination and let both index\nscans finish. Since the two indexes both have proper cost, we\nincorrectly determined at runtime that the intersect scan is\nchosen by CBO while in reality it is not. Since one of the\nindexes scans >95% of the index we timed out at runtime.\n\nTo fix this, we now \"reset\" useCBO in the function such that\nwhen intersect scan is considered, we check and see whether\nall remaining indexes have proper cost, and if so, still let\nCBO choose the intersect scan, even if we've turned CBO off\nin the function previously.\n\nAlso avoid calculating cost in case of \"shortest == false\",\nsince in that case we've not generated the index spans\nand thus there is no point in trying to calculating cost\n(this part behaves differently in 7.2 vs 7.6).\n\nChange-Id: If4293f78cf6cf93626314487b681dbe491278695\nReviewed-on: https://review.couchbase.org/c/query/+/210653\nReviewed-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker\nTested-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-62073 Allow CBO to choose intersect scan ..."}},{"before":"2337efef56130397cae30d2e7d74e8cff0a4b29c","after":"08e85bd9c3a38320e0ea809537d4268ca72c4ed1","ref":"refs/heads/trinity","pushedAt":"2024-05-29T14:57:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62059 Proper generation of array index key in index advisor\n\nThe index advisor generates array index keys by evaluating the\nANY clause used in the query. For this bug, a non-traditiional\nANY clause is used:\n\n ANY i IN [1,2] SATISFIES i = id END\n\nnote that teh binding is referencing a constant array construct.\nThe index advisor is not handling this form well and generates\nan invalid syntax for the array index key.\n\nSeveral changes are made to address this issue:\n\n - add a \"phase\" when gathering array index construct, such\n that we can differentiate between the \"binding\" and the\n \"satisfies\" clauses of the ANY expression\n - after gathering from the bindings, if there is no\n \"indexName\" generated, i.e. the binding is not referring\n to the source keyspace, then bail out\n - when handling constants, only return the constant\n expression if the phase is in \"satisfies\", i.e. ignore\n the constants if handling \"bindings\"\n\nAfter these changes, the index advisor now generates a\nmessage indicating no index recommendation is available.\n\nChange-Id: I82413d65dce32a0230a95f5668d05831b3edd6d1\nReviewed-on: https://review.couchbase.org/c/query/+/210612\nReviewed-by: Sitaram Vemulapalli \nTested-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker","shortMessageHtmlLink":"MB-62059 Proper generation of array index key in index advisor"}},{"before":"2e5b5006e27f1b3c2b75c1b3525dd0e823bdfe8f","after":"fe1182d5129553684725c7f9ae16ce604c5e9a96","ref":"refs/heads/neo","pushedAt":"2024-05-25T19:01:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-62042 Update with all date function changes...\n\n... from later versions.\n\nChange-Id: Id5ef536baa4ac8f22b489779e328d6ac4ebc5bbb\nReviewed-on: https://review.couchbase.org/c/query/+/210459\nTested-by: Bingjie Miao \nReviewed-by: Bingjie Miao ","shortMessageHtmlLink":"MB-62042 Update with all date function changes..."}},{"before":"30bc0f3466ebfdd66da9271b0eac49bffc307674","after":"613b10f958daec29172510c7183b08d29e11aec3","ref":"refs/heads/master","pushedAt":"2024-05-23T17:33:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60680 Fix early order for vector index key\n\nChange-Id: I0d83ea4da178ff59fcf4b3f493cda83f6cf091f6\nReviewed-on: https://review.couchbase.org/c/query/+/210422\nTested-by: Sitaram Vemulapalli \nReviewed-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-60680 Fix early order for vector index key"}},{"before":"aada51e66e6a18bd94593d5ae34d3bb3f85b54c1","after":"30bc0f3466ebfdd66da9271b0eac49bffc307674","ref":"refs/heads/master","pushedAt":"2024-05-22T22:29:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60680 Fix index order for vector index key\n\nChange-Id: Iebea9b3d71a95ab37d652af4a8f715505f536f9b\nReviewed-on: https://review.couchbase.org/c/query/+/210375\nTested-by: Sitaram Vemulapalli \nReviewed-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-60680 Fix index order for vector index key"}},{"before":"56123b2b62b1e34cf63d6a105327f84ef48ae202","after":"aada51e66e6a18bd94593d5ae34d3bb3f85b54c1","ref":"refs/heads/master","pushedAt":"2024-05-22T17:26:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60680 Fix version in index api\n\nChange-Id: Ic041e58fb8d3eb29871be3f1f08cca5a0175522f\nReviewed-on: https://review.couchbase.org/c/query/+/210359\nReviewed-by: Sitaram Vemulapalli \nTested-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-60680 Fix version in index api"}},{"before":"420e938607006e05a68f9c88f6ccc882306c927b","after":"56123b2b62b1e34cf63d6a105327f84ef48ae202","ref":"refs/heads/master","pushedAt":"2024-05-22T16:39:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60680 vector index\n\nChange-Id: Icde9f1eb407410810b6d8313085b038bac7c7ca6\nReviewed-on: https://review.couchbase.org/c/query/+/210236\nReviewed-by: Donald Haggart \nTested-by: Bingjie Miao ","shortMessageHtmlLink":"MB-60680 vector index"}},{"before":"d8bba4e44b2bfcc263328e6ec36c4175436c301c","after":"420e938607006e05a68f9c88f6ccc882306c927b","ref":"refs/heads/master","pushedAt":"2024-05-22T09:53:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"Fix unit test failure.\n\nChange-Id: I1a83b1328d6009e0d325d9c3ffbca2a4b7c446b4\nReviewed-on: https://review.couchbase.org/c/query/+/210345\nTested-by: Donald Haggart \nReviewed-by: Gaurav J ","shortMessageHtmlLink":"Fix unit test failure."}},{"before":"d9afb8d20fb5d02f10b412eee104c36f7eebdb5b","after":"d8bba4e44b2bfcc263328e6ec36c4175436c301c","ref":"refs/heads/master","pushedAt":"2024-05-21T22:56:52.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"Merge remote-tracking branch 'couchbase/trinity'\n\nChange-Id: I7b428768938caf59258c4286970c6c72bf6035ef","shortMessageHtmlLink":"Merge remote-tracking branch 'couchbase/trinity'"}},{"before":"864b9e9af05b3cae408461b5ad9d3c5369b8a2b1","after":"2337efef56130397cae30d2e7d74e8cff0a4b29c","ref":"refs/heads/trinity","pushedAt":"2024-05-21T22:07:55.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-59575, MB-60943: go mod tidy\n\nChange-Id: Id709b7c59a08bf40d75612f5abce0bfcba30595f\nReviewed-on: https://review.couchbase.org/c/query/+/210089\nWell-Formed: Restriction Checker\nTested-by: Abhi Dangeti \nReviewed-by: Abhi Dangeti ","shortMessageHtmlLink":"MB-59575, MB-60943: go mod tidy"}},{"before":"92b149ed334f2522b6cc4b731ff891d49bfb186b","after":"d9afb8d20fb5d02f10b412eee104c36f7eebdb5b","ref":"refs/heads/master","pushedAt":"2024-05-21T04:02:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-61772 Add error message\n- E_RECURSIVE_IMPLICIT_DEPTH_LIMIT(3306)\n- E_CYCLE_FIELDS_VALIDATION_FAILED(3307)\n\nChange-Id: Iad23d7eed541a8b2b026941eecc6cca4936af78b\nReviewed-on: https://review.couchbase.org/c/query/+/210139\nReviewed-by: Donald Haggart \nTested-by: Gaurav J ","shortMessageHtmlLink":"MB-61772 Add error message"}},{"before":"17bf23d1915e53b0327b2aa18e7afa8a3e5e4a62","after":"92b149ed334f2522b6cc4b731ff891d49bfb186b","ref":"refs/heads/master","pushedAt":"2024-05-17T16:12:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60646 Add error description...\n\n... for E_NO_INDEX_SERVICE.\n\nChange-Id: Ia08ac65cbdb871309081e9ec6e500865ffe1f641\nReviewed-on: https://review.couchbase.org/c/query/+/210161\nReviewed-by: Bingjie Miao \nTested-by: Bingjie Miao ","shortMessageHtmlLink":"MB-60646 Add error description..."}},{"before":"d0e10b2a4c624e7043cbf1645a6c8685f0f8852e","after":"17bf23d1915e53b0327b2aa18e7afa8a3e5e4a62","ref":"refs/heads/master","pushedAt":"2024-05-17T09:58:22.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"Merge remote-tracking branch 'origin/trinity' into master-merge\n\nChange-Id: I7438fcb363bbf475cabc5ea704befe54c3dbcea4","shortMessageHtmlLink":"Merge remote-tracking branch 'origin/trinity' into master-merge"}},{"before":"fb09733ea0e49d1f648b48f94e0b83dc799e31e3","after":"d0e10b2a4c624e7043cbf1645a6c8685f0f8852e","ref":"refs/heads/master","pushedAt":"2024-05-16T23:14:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60680 Add HasVector() to flatten keys expression\n\nChange-Id: Ib0d23036cf21df326112440f0cdfabd91b4717e7\nReviewed-on: https://review.couchbase.org/c/query/+/210107\nTested-by: \nReviewed-by: Sitaram Vemulapalli \nReviewed-by: \nTested-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-60680 Add HasVector() to flatten keys expression"}},{"before":"cd42845cd32b97718597d818c34851f5119c8e8d","after":"864b9e9af05b3cae408461b5ad9d3c5369b8a2b1","ref":"refs/heads/trinity","pushedAt":"2024-05-16T15:33:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-61760 [BP 33961] ORDER BY optimisation\n\nCommit 0070ac076 ported the check for offset operator condition portion\nof 33961 to 7.6 but this has side effects when the rest of the change\nisn't present. Since this change is relatively small and contained\nporting the whole change back makes most sense (and addresses the issues\ncaused by commit 0070ac076).\n\nChange-Id: Ib2a58aa1ddd44d6512df6d675f59aa23c93def5e\nReviewed-on: https://review.couchbase.org/c/query/+/210064\nReviewed-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker\nReviewed-by: Bingjie Miao \nTested-by: Sitaram Vemulapalli ","shortMessageHtmlLink":"MB-61760 [BP 33961] ORDER BY optimisation"}},{"before":"1db801b2a056c300559fd8b4eb8e475a9d5726cd","after":"cd42845cd32b97718597d818c34851f5119c8e8d","ref":"refs/heads/trinity","pushedAt":"2024-05-16T02:33:27.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-61772 Refactor Recursive CTE\n\n1) Reduce Memory Usage\n - reuse of slice wherever possible\n - reduce redundant call to json.Marshal() when forming keys for union/cycle-restrict\n\n2) dedup and cycle restrict logic in one pass instead of two.\n\n3) validation of cyclefields now is done in the planner, and errors out if a cycle-field expression is not\n an identifier or path.\n\n4) during cycle-restrict if we are not able to generate a subset of the item from the cycle-fields provided,\n we error out instead of silently discarding the item.\n\nChange-Id: Ib03913b5f6ce9e13f5d5a78a0ffe2ad95ca8b092\nReviewed-on: https://review.couchbase.org/c/query/+/209223\nWell-Formed: Restriction Checker\nReviewed-by: Bingjie Miao \nTested-by: Bingjie Miao ","shortMessageHtmlLink":"MB-61772 Refactor Recursive CTE"}},{"before":"0070ac076a6fd8f8cc4bb43932a76acaeb4f8d19","after":"1db801b2a056c300559fd8b4eb8e475a9d5726cd","ref":"refs/heads/trinity","pushedAt":"2024-05-15T04:46:15.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ns-codereview","name":null,"path":"/ns-codereview","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/318262?s=80&v=4"},"commit":{"message":"MB-60646 Augment \"No index available\" message...\n\n... to note checking the index service is available as a cluster may be\ncreated without the service and the message suggests an index creation\nstatement. (Done this way so that the primary message text is\nunchanged.)\n\nDetect when there are no Index nodes and don't attempt to create a\nprimary index on the system collection in this case.\n\nAlso forcibly enable sequential scans for the system collection. In the\nabsence of a GSI indexer we do still need to be able to scan our\nmetadata.\n\nChange-Id: If5bd06302015bc9b53fa9d36bedf2dfcbdaff04b\nReviewed-on: https://review.couchbase.org/c/query/+/209825\nReviewed-by: Bingjie Miao \nTested-by: Donald Haggart \nReviewed-by: Sitaram Vemulapalli \nWell-Formed: Restriction Checker","shortMessageHtmlLink":"MB-60646 Augment \"No index available\" message..."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEX4PMOQA","startCursor":null,"endCursor":null}},"title":"Activity ยท couchbase/query"}