Skip to content

[Feature] percentfield and showperc with top and rare commands. - #5642

Open
AjimelecGonzalez wants to merge 1 commit into
opensearch-project:mainfrom
AjimelecGonzalez:feature/showperc
Open

[Feature] percentfield and showperc with top and rare commands.#5642
AjimelecGonzalez wants to merge 1 commit into
opensearch-project:mainfrom
AjimelecGonzalez:feature/showperc

Conversation

@AjimelecGonzalez

@AjimelecGonzalez AjimelecGonzalez commented Jul 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Description

Add percentfield and showperc options to the top and rare PPL commands. When showperc=true is specified, a percent column is added to the output showing each value's percentage of the total count within its partition (group-by clause). The percentfield option allows customizing the name of the percentage column (default: percent).

The percentage is computed as ROUND(100.0 * count / SUM(count) OVER (PARTITION BY group_fields), 6) and is rounded to 6 decimal places. When used with a by clause, percentages are calculated within each partition (summing to 100% per group).

Syntax

source=index | top [percentfield='<name>'] showperc=true field_name [by group_field]
source=index | rare [percentfield='<name>'] showperc=true field_name [by group_field]

Top Example

source=otellogs | top showperc=true severityText

Returns:

severityText count percent
ERROR 7 35.0
INFO 6 30.0
WARN 4 20.0
DEBUG 3 15.0

Rare Example

source=otellogs | rare showperc=true severityText

Returns:

severityText count percent
DEBUG 3 15.0
WARN 4 20.0
INFO 6 30.0
ERROR 7 35.0

Custom Percentage Field Name Example

source=otellogs | top percentfield='pct' showperc=true severityText

Returns:

severityText count pct
ERROR 7 35.0
INFO 6 30.0
WARN 4 20.0
DEBUG 3 15.0

Related Issues

Resolves #5530

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • New functionality has javadoc added.
  • New functionality has a user manual doc added.
  • New PPL command checklist all confirmed.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff or -s.
  • Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@github-actions

github-actions Bot commented Jul 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

PR Reviewer Guide 🔍

(Review updated until commit ca50dab)

Here are some key observations to aid the review process:

🧪 PR contains tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ Recommended focus areas for review

Typo Fixed

The old code had a typo 'countield' instead of 'countfield'. The new code fixes this typo. While this is a correction, it changes the output format of anonymized queries. If any external system or test relies on the exact string format of anonymized queries (including the typo), this could break compatibility. However, this is likely an improvement rather than a defect.

 
    "countfield='%s' showcount=%s percentfield='%s' showperc=%s usenull=%s ",
    countField, showCount, percentField, showPerc, useNull)
: "";

@github-actions

github-actions Bot commented Jul 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

PR Code Suggestions ✨

Latest suggestions up to ca50dab

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
Possible issue
Handle division by zero

The percentage calculation doesn't handle the case where totalWindowOver is zero or
null, which could result in division by zero errors or null propagation. Add a null
check or use a CASE expression to return 0 or null when the total is zero.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3291-3296]

 RexNode hundred = context.relBuilder.literal(new BigDecimal("100.0"));
 RexNode countCast =
     context.relBuilder.cast(context.relBuilder.field(countFieldName), SqlTypeName.DOUBLE);
 RexNode totalCast = context.relBuilder.cast(totalWindowOver, SqlTypeName.DOUBLE);
 RexNode numerator = context.relBuilder.call(SqlStdOperatorTable.MULTIPLY, hundred, countCast);
-RexNode percValue = context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast);
+RexNode zero = context.relBuilder.literal(0.0);
+RexNode isZero = context.relBuilder.equals(totalCast, zero);
+RexNode division = context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast);
+RexNode percValue = context.relBuilder.call(SqlStdOperatorTable.CASE, isZero, zero, division);
Suggestion importance[1-10]: 7

__

Why: The suggestion correctly identifies a potential division by zero issue in the percentage calculation. While the scenario is unlikely in typical use (requires all counts to be zero), adding protection would improve robustness. However, the suggested fix using CASE may not be the most idiomatic approach for Calcite's RexNode API, and the score is moderate because this is a defensive programming improvement rather than fixing an actual bug in normal operation.

Medium

Previous suggestions

Suggestions up to commit 840ef88
CategorySuggestion                                                                                                                                    Impact
Possible issue
Handle division by zero in percentage

The percentage calculation doesn't handle the case where totalCast could be zero,
which would result in division by zero. Add a check or use a CASE expression to
handle this edge case and prevent runtime errors.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3257-3262]

 RexNode hundred = context.relBuilder.literal(new BigDecimal("100.0"));
 RexNode countCast =
     context.relBuilder.cast(context.relBuilder.field(countFieldName), SqlTypeName.DOUBLE);
 RexNode totalCast = context.relBuilder.cast(totalWindowOver, SqlTypeName.DOUBLE);
+RexNode zero = context.relBuilder.literal(0.0);
 RexNode numerator = context.relBuilder.call(SqlStdOperatorTable.MULTIPLY, hundred, countCast);
-RexNode percValue = context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast);
+RexNode percValue = context.relBuilder.call(
+    SqlStdOperatorTable.CASE,
+    context.relBuilder.call(SqlStdOperatorTable.EQUALS, totalCast, zero),
+    zero,
+    context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast));
Suggestion importance[1-10]: 7

__

Why: This is a valid concern about potential division by zero when totalWindowOver (the sum of counts) is zero. However, in the context of rare/top commands, this scenario is unlikely since these commands operate on aggregated data where at least one row must exist. Still, adding defensive programming for edge cases is good practice and would prevent potential runtime errors.

Medium
General
Add duplicate field check for count

The duplicate field check should also be performed for countFieldName to prevent
conflicts when both count and percent fields are shown. This ensures consistency
with the error handling pattern and prevents potential field name collisions.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3241-3246]

 if (context.relBuilder.peek().getRowType().getFieldNames().contains(percentFieldName)) {
   throw new IllegalArgumentException(
       "Field `"
           + percentFieldName
           + "` already exists in the output. Consider renaming with percentfield='xyz'");
 }
+if (context.relBuilder.peek().getRowType().getFieldNames().contains(countFieldName)) {
+  throw new IllegalArgumentException(
+      "Field `"
+          + countFieldName
+          + "` already exists in the output. Consider renaming with countfield='xyz'");
+}
Suggestion importance[1-10]: 6

__

Why: The suggestion correctly identifies that countFieldName should also be checked for duplicates, similar to percentFieldName. However, this check should occur earlier in the code flow (before the percentage calculation block), and the existing code already handles count field conflicts in the earlier aggregation step at line 3225. The suggestion has merit but may be redundant given the existing logic.

Low
Suggestions up to commit 19f05c0
CategorySuggestion                                                                                                                                    Impact
Possible issue
Handle division by zero scenario

Division by zero can occur when the total count is zero (empty partition). Add a
null check or use a CASE expression to handle this edge case and prevent potential
runtime errors or NaN values in the output.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3291-3296]

 RexNode hundred = context.relBuilder.literal(new BigDecimal("100.0"));
 RexNode countCast =
     context.relBuilder.cast(context.relBuilder.field(countFieldName), SqlTypeName.DOUBLE);
 RexNode totalCast = context.relBuilder.cast(totalWindowOver, SqlTypeName.DOUBLE);
 RexNode numerator = context.relBuilder.call(SqlStdOperatorTable.MULTIPLY, hundred, countCast);
-RexNode percValue = context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast);
+RexNode zero = context.relBuilder.literal(0.0);
+RexNode isZero = context.relBuilder.equals(totalCast, zero);
+RexNode percValue = context.relBuilder.call(
+    SqlStdOperatorTable.CASE,
+    isZero,
+    zero,
+    context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast));
Suggestion importance[1-10]: 7

__

Why: This is a valid concern about potential division by zero when totalWindowOver is zero (empty partition). The suggested CASE expression would prevent NaN or error values. However, in practice, the total count from SUM(COUNT(*)) over a partition should never be zero if there are rows in that partition, making this an edge case that may not occur in normal operation.

Medium
General
Add duplicate field check for count

The duplicate field check should also be performed for countFieldName to prevent
conflicts when both count and percent fields are shown. This ensures consistency
with the error handling pattern and prevents potential field name collisions.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3275-3280]

 if (context.relBuilder.peek().getRowType().getFieldNames().contains(percentFieldName)) {
   throw new IllegalArgumentException(
       "Field `"
           + percentFieldName
           + "` already exists in the output. Consider renaming with percentfield='xyz'");
 }
+if (context.relBuilder.peek().getRowType().getFieldNames().contains(countFieldName)) {
+  throw new IllegalArgumentException(
+      "Field `"
+          + countFieldName
+          + "` already exists in the output. Consider renaming with countfield='xyz'");
+}
Suggestion importance[1-10]: 5

__

Why: The suggestion correctly identifies that countFieldName should also be checked for duplicates, similar to percentFieldName. However, the countFieldName field is added earlier in the code (before line 3269), so this check would need to be placed before that point to be effective. The suggestion's placement after the percent field check is logically inconsistent with the code flow.

Low
Suggestions up to commit 840ef88
CategorySuggestion                                                                                                                                    Impact
Possible issue
Handle division by zero in percentage

Division by zero can occur when totalWindowOver is zero (empty partition or all null
values). This will cause runtime errors or produce NaN/Infinity values in the
percentage calculation.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3257-3262]

 RexNode hundred = context.relBuilder.literal(new BigDecimal("100.0"));
 RexNode countCast =
     context.relBuilder.cast(context.relBuilder.field(countFieldName), SqlTypeName.DOUBLE);
 RexNode totalCast = context.relBuilder.cast(totalWindowOver, SqlTypeName.DOUBLE);
 RexNode numerator = context.relBuilder.call(SqlStdOperatorTable.MULTIPLY, hundred, countCast);
-RexNode percValue = context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast);
+RexNode zero = context.relBuilder.literal(0.0);
+RexNode percValue = context.relBuilder.call(
+    SqlStdOperatorTable.CASE,
+    context.relBuilder.call(SqlStdOperatorTable.EQUALS, totalCast, zero),
+    zero,
+    context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast));
Suggestion importance[1-10]: 8

__

Why: This identifies a legitimate edge case where division by zero could occur when totalWindowOver is zero (empty partition). The suggestion provides a proper CASE statement to handle this scenario, preventing potential runtime errors or NaN/Infinity values in percentage calculations.

Medium
Prevent percentfield and countfield name collision

The duplicate field check should also verify against countFieldName to prevent
conflicts when both fields are shown. If percentFieldName equals countFieldName,
this creates ambiguity in the output schema.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3241-3246]

 if (context.relBuilder.peek().getRowType().getFieldNames().contains(percentFieldName)) {
   throw new IllegalArgumentException(
       "Field `"
           + percentFieldName
           + "` already exists in the output. Consider renaming with percentfield='xyz'");
 }
+if (percentFieldName.equals(countFieldName)) {
+  throw new IllegalArgumentException(
+      "percentfield and countfield cannot have the same name: `" + percentFieldName + "`");
+}
Suggestion importance[1-10]: 7

__

Why: The suggestion correctly identifies a potential issue where percentFieldName and countFieldName could have the same value, causing schema ambiguity. However, this is a validation check that asks users to verify their input rather than fixing a critical bug, so it should not receive a score above 7.

Medium
Suggestions up to commit 3bea92e
CategorySuggestion                                                                                                                                    Impact
Possible issue
Handle division by zero in percentage

Division by zero can occur when totalWindowOver is zero (empty partition or all null
values). This will result in NaN or Infinity values in the percent field. Add a
check or use a CASE expression to handle this edge case gracefully.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3260-3262]

 RexNode totalCast = context.relBuilder.cast(totalWindowOver, SqlTypeName.DOUBLE);
 RexNode numerator = context.relBuilder.call(SqlStdOperatorTable.MULTIPLY, hundred, countCast);
-RexNode percValue = context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast);
+RexNode zero = context.relBuilder.literal(0.0);
+RexNode isZero = context.relBuilder.equals(totalCast, zero);
+RexNode percValue = context.relBuilder.call(
+    SqlStdOperatorTable.CASE,
+    isZero,
+    zero,
+    context.relBuilder.call(SqlStdOperatorTable.DIVIDE, numerator, totalCast));
Suggestion importance[1-10]: 7

__

Why: Valid concern about division by zero when totalWindowOver is zero. This could occur with empty partitions or all-null values, resulting in NaN or Infinity. The suggested CASE expression would handle this gracefully by returning 0.0 instead of attempting division. This is a defensive programming practice that improves robustness.

Medium
General
Add duplicate field validation for count

The duplicate field check for percentFieldName should also be performed for
countFieldName to prevent conflicts. Currently, only the percent field is validated,
but the count field could also collide with existing fields in the output schema.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3241-3246]

 if (context.relBuilder.peek().getRowType().getFieldNames().contains(percentFieldName)) {
   throw new IllegalArgumentException(
       "Field `"
           + percentFieldName
           + "` already exists in the output. Consider renaming with percentfield='xyz'");
 }
+if (context.relBuilder.peek().getRowType().getFieldNames().contains(countFieldName)) {
+  throw new IllegalArgumentException(
+      "Field `"
+          + countFieldName
+          + "` already exists in the output. Consider renaming with countfield='xyz'");
+}
Suggestion importance[1-10]: 6

__

Why: The suggestion correctly identifies that countFieldName should also be validated for duplicates, similar to percentFieldName. However, this validation should occur earlier in the code flow (before the percentage calculation block), where the count field is first introduced. The impact is moderate as it prevents potential field name conflicts.

Low
Suggestions up to commit 84c6094
CategorySuggestion                                                                                                                                    Impact
General
Move duplicate field validation earlier

The duplicate field check for percentFieldName occurs after the percentage
computation logic begins, but a similar check for countFieldName exists earlier in
the code (around line 3200). Move this validation to occur immediately after
retrieving percentFieldName from the argument map, alongside the countFieldName
validation, to fail fast and maintain consistency.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3241-3246]

+String percentFieldName =
+    (String) argumentMap.get(RareTopN.Option.percentField.name()).getValue();
+
 if (context.relBuilder.peek().getRowType().getFieldNames().contains(percentFieldName)) {
   throw new IllegalArgumentException(
       "Field `"
           + percentFieldName
           + "` already exists in the output. Consider renaming with percentfield='xyz'");
 }
Suggestion importance[1-10]: 4

__

Why: The suggestion to move the validation earlier for consistency is reasonable but has limited impact. The current placement still validates before use, and the suggested improvement is primarily about code organization rather than fixing a bug or preventing an error.

Low
Extract percentFieldName before conditional block

The percentFieldName is retrieved inside the if (showPerc) block but is only used
when showPerc is true. However, if showPerc is false, the percentFieldName argument
is still parsed and stored. Consider validating that percentFieldName is not already
in use even when showPerc=false, or document why this validation is conditional.

core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [3236-3246]

+String percentFieldName =
+    (String) argumentMap.get(RareTopN.Option.percentField.name()).getValue();
 Boolean showPerc = (Boolean) argumentMap.get(RareTopN.Option.showPerc.name()).getValue();
+
 if (showPerc) {
-  String percentFieldName =
-      (String) argumentMap.get(RareTopN.Option.percentField.name()).getValue();
+  if (context.relBuilder.peek().getRowType().getFieldNames().contains(percentFieldName)) {
+    throw new IllegalArgumentException(
+        "Field `"
+            + percentFieldName
+            + "` already exists in the output. Consider renaming with percentfield='xyz'");
+  }
   ...
 }
Suggestion importance[1-10]: 3

__

Why: The suggestion to extract percentFieldName outside the conditional block is questionable. The current implementation correctly retrieves percentFieldName only when needed (showPerc=true). Extracting it unconditionally would be less efficient and the validation concern raised is not compelling since the field is only added to output when showPerc=true.

Low

@github-actions

github-actions Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit ca7e450

@github-actions

github-actions Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit dae1ecd

@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 0b5b6ed

@ahkcs ahkcs added the feature label Jul 22, 2026
ahkcs
ahkcs reviewed Jul 22, 2026
View reviewed changes
Comment thread integ-test/src/test/java/org/opensearch/sql/calcite/remote/CalciteTopCommandIT.java
Comment thread integ-test/src/test/java/org/opensearch/sql/calcite/remote/CalciteTopCommandIT.java
Comment thread integ-test/src/test/java/org/opensearch/sql/ppl/TopCommandIT.java
Comment thread core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java Outdated
Comment thread core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java
@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit 0039627.

PathLineSeverityDescription
core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java3237lowConflict-detection check tests for misspelled field name 'precent' instead of 'percent', so the guard against duplicate output fields will never fire. This renders the protective error message dead code, meaning a user with a pre-existing 'percent' field will get a silently incorrect result rather than the intended error. Appears to be a typo rather than intentional, but worth flagging as an anomaly.

The table above displays the top 10 most important findings.

Total: 1 | Critical: 0 | High: 0 | Medium: 0 | Low: 1

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 0039627

@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit b576e5a

@github-actions

github-actions Bot commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit be841df

@github-actions

github-actions Bot commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 84c6094

@github-actions

github-actions Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 3bea92e

@AjimelecGonzalez AjimelecGonzalez changed the title [Feature] showperc with top and rare commands. [Feature] showperc and percentfield with top and rare commands. Jul 30, 2026
@AjimelecGonzalez AjimelecGonzalez changed the title [Feature] showperc and percentfield with top and rare commands. [Feature] percentfield and showperc with top and rare commands. Jul 30, 2026
@github-actions

github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 840ef88

@github-actions

github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 19f05c0

@github-actions

github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 840ef88

@AjimelecGonzalez
[Feature] percentfield and showperc with top and rare commands.
ca50dab 
* Clean docs
* Fix CalcitePPLRareTopNTest showperc tests
* Calculate percentages before filtering
* Added percentfield and changed decimal places from 2 to 6
* Update test errors, SUM to CHECKED_LONG_SUM

Signed-off-by: Ajimelec Gonzalez <ajimelec@amazon.com>
@github-actions

github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit ca50dab

Swiddis
Swiddis reviewed Jul 30, 2026
View reviewed changes
Comment thread core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java
Comment on lines +3242 to +3245
throw new IllegalArgumentException(
"Field `"
+ percentFieldName
+ "` already exists in the output. Consider renaming with percentfield='xyz'");

@Swiddis Swiddis Jul 30, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Would it be better user experience if we provided a new percent field automatically?

e.g. generate percent0, percent1, etc. Joins already do this with join IDs (id -> id0, etc).

@AjimelecGonzalez AjimelecGonzalez Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, will remove the check.

Comment thread core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java
List.of(),
partitionKeys,
List.of(),
WindowFrame.rowsUnbounded());

@Swiddis Swiddis Jul 30, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: This has a correctness issue for high-cardinality fields because the total is based on the returned buckets.

The current impl works well for low-cardinality fields, but for high cardinality we get a truncated bucket set. I'm worried about long-tail types of top-N cases (e.g. "top 10 endpoints" from a service with many assets). rare would be much more affected in that case.

In principle we should be using the sum_other_doc_count value that's returned by aggregations if it's available: https://docs.opensearch.org/latest/aggregations/bucket/terms/#example-response. But fixing may be complex depending on the exact conditions where that value is present, I don't know them off the top but it may only apply to term aggregations and not composite aggs, and it means percent aggregations need to be finalized at the coordinator. If it's not available then the "right" way is to submit a whole separate _count request but that'll complicate query flow.

If it's a lot to patch, I think we can leave this behavior, but should document the limitation. You can manually work around it by using a subquery or something like eventstats to work with stats count() computed ahead of time. (Alternatively, if such a method exists, we could rewrite the query plan to be equivalent to it.)

@AjimelecGonzalez AjimelecGonzalez Jul 31, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will look into it and document, I believe that the using the sum_other_doc_count value would be the best choice here but will have to deep dive. For now I will add the limitations to the md file for top and rare commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Swiddis Swiddis Swiddis left review comments
@ahkcs ahkcs ahkcs approved these changes
@ps48 ps48 Awaiting requested review from ps48 ps48 is a code owner
@joshuali925 joshuali925 Awaiting requested review from joshuali925 joshuali925 is a code owner
@dai-chen dai-chen Awaiting requested review from dai-chen dai-chen is a code owner
@mengweieric mengweieric Awaiting requested review from mengweieric mengweieric is a code owner
@vamsimanohar vamsimanohar Awaiting requested review from vamsimanohar vamsimanohar is a code owner
@penghuo penghuo Awaiting requested review from penghuo penghuo is a code owner
@anirudha anirudha Awaiting requested review from anirudha anirudha is a code owner
@acarbonetto acarbonetto Awaiting requested review from acarbonetto acarbonetto is a code owner
@ykmr1224 ykmr1224 Awaiting requested review from ykmr1224 ykmr1224 is a code owner
@LantaoJin LantaoJin Awaiting requested review from LantaoJin LantaoJin is a code owner
@noCharger noCharger Awaiting requested review from noCharger noCharger is a code owner
@qianheng-aws qianheng-aws Awaiting requested review from qianheng-aws qianheng-aws is a code owner
@yuancu yuancu Awaiting requested review from yuancu yuancu is a code owner
@RyanL1997 RyanL1997 Awaiting requested review from RyanL1997 RyanL1997 is a code owner
@songkant-aws songkant-aws Awaiting requested review from songkant-aws songkant-aws is a code owner

Assignees

No one assigned

Labels

feature

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[FEATURE] showperc with top

3 participants

@AjimelecGonzalez @Swiddis @ahkcs