Multi stage metrics

[gortiz]

This PR adds some multi-stage metrics. The whole PR is built on top of #12704 so it should only be merged once (and if) that other PR is merged.

All new metrics are server based. Specifically, they are:

• Meters:

  • HASH_JOIN_TIMES_MAX_ROWS_REACHED (global): How many times the max number of rows per join has been reached. If this happens multiple times in a single query, the meter will be increased as many times as this limit is reached.
  • AGGREGATE_TIMES_NUM_GROUPS_LIMIT_REACHED (global): How many times the max number of groups has been reached. If this happens multiple times in a single query, the meter will be increased as many times as this limit is reached.
  • MAX_ROWS_IN_WINDOW_REACHED (global): How many times the max number of elements in window has been reached. If this happens multiple times in a single query, the meter will be increased as many times as the limit is reached.
  • MULTI_STAGE_IN_MEMORY_MESSAGES (global): How many messages have been sent from one stage to the other without being serialized. Optimizations like collocated joins can increase this number.
  • MULTI_STAGE_RAW_MESSAGES (global): How many times messages have been sent from one stage to the other in serialized way. Optimizations like collocated joins can reduce this number.
  • MULTI_STAGE_RAW_BYTES (global): How many bytes have been sent from one stage to the other. The smaller this number, the better.

• Timers

  • HASH_JOIN_CPU_TIME_BUILDING_HASH_TABLE_MS (global): The CPU time (in ms) spent building the hash table on each hash join.
  • MULTI_STAGE_SERIALIZATION_CPU_TIME_MS (global): The CPU time (in ms) spent when messages are being serialized from one stage to the other.
  • MULTI_STAGE_DESERIALIZATION_CPU_TIME_MS (global): The CPU time (in ms) spent when messages are being deserialized after being received by other stage.
  • RECEIVE_DOWNSTREAM_CPU_TIME_MS (global): The CPU time (in ms) spent by sender mailboxes waiting the receiver (upstream) to read the messages.
  • RECEIVE_UPSTREAM_CPU_WAIT_MS (global): The CPU time (in ms) spent by receiver mailboxes waiting for new data from the sender (upstream).

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 89.18919% with 8 lines in your changes missing coverage. Please review.

Project coverage is 62.05%. Comparing base (59551e4) to head (58676cb).
Report is 564 commits behind head on master.

Files	Patch %	Lines
...not/query/runtime/operator/MultiStageOperator.java	89.47%	2 Missing and 2 partials ⚠️
...ot/query/runtime/operator/MailboxSendOperator.java	86.66%	1 Missing and 1 partial ⚠️
...pinot/query/runtime/plan/MultiStageQueryStats.java	75.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #13035      +/-   ##
============================================
+ Coverage     61.75%   62.05%   +0.30%     
+ Complexity      207      198       -9     
============================================
  Files          2436     2544     +108     
  Lines        133233   139740    +6507     
  Branches      20636    21611     +975     
============================================
+ Hits          82274    86720    +4446     
- Misses        44911    46532    +1621     
- Partials       6048     6488     +440     

Flag	Coverage Δ
custom-integration1	<0.01% <0.00%> (-0.01%)	⬇️
integration	<0.01% <0.00%> (-0.01%)	⬇️
integration1	<0.01% <0.00%> (-0.01%)	⬇️
integration2	0.00% <0.00%> (ø)
java-11	62.02% <89.18%> (+0.31%)	⬆️
java-21	61.94% <89.18%> (+0.32%)	⬆️
skip-bytebuffers-false	62.04% <89.18%> (+0.29%)	⬆️
skip-bytebuffers-true	61.92% <89.18%> (+34.20%)	⬆️
temurin	62.05% <89.18%> (+0.30%)	⬆️
unittests	62.05% <89.18%> (+0.30%)	⬆️
unittests1	46.61% <89.18%> (-0.28%)	⬇️
unittests2	27.73% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Jackie-Jiang]

Mostly good

[Jackie-Jiang]

Since this is internal only code, we can skip wrapping into unmodifiable to reduce overhead

[gortiz]

A unmodifiable list is very light (just an indirection) and TBH I prefer to be a bit paranoic here so we don't end up modifying it in the future, which would be difficult to catch.

This method is only called once per query on the broker. I don't think creating a single small object (that can be probably scalar replaced) would be problematic.

[Jackie-Jiang]

LGTM!