Skip to content

metrics: added more metrics for multi-column group by#19526

Open
rluvaton wants to merge 5 commits intoapache:mainfrom
rluvaton:add-more-metrics-for-row-hash
Open

metrics: added more metrics for multi-column group by#19526
rluvaton wants to merge 5 commits intoapache:mainfrom
rluvaton:add-more-metrics-for-row-hash

Conversation

@rluvaton
Copy link
Copy Markdown
Member

@rluvaton rluvaton commented Dec 28, 2025

Which issue does this PR close?

N/A

Rationale for this change

The first step in looking for a problem in client env is by metrics, and we currently have no metrics for multi group by aggregation (as well as other types of group by - single column and row based) so this add some

What changes are included in this PR?

Added metrics for time hashing, building hash map and maximum length and capacity for the hash map for multi group by

I would like to add metrics for the vectorized_append and vectorized_equal_to as well but I don't have a good name for them that do not leak internal implementation

Are these changes tested?

No

Are there any user-facing changes?

Yes

@github-actions github-actions Bot added the physical-plan Changes to the physical-plan crate label Dec 28, 2025
Copy link
Copy Markdown
Contributor

@kosiew kosiew left a comment

Choose a reason for hiding this comment

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

@rluvaton
Thanks for the initiative.
I left some questions and a suggestion.

Comment on lines +69 to +70
/// Maximum hash map capacity
pub(crate) maximum_hash_map_capacity: Gauge,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

is this tracking the HashTable's initial capacity, or how it grows during execution? When is this useful vs. maximum_number_of_entries_in_map?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

How it grows during execution.

This is different than max number of elements as you can't know from max number of elements if the hash map fit in cache and which cache. Because unlike vector which only the number of elements is used and you can know if it fit in the cache, in hash map it is scattered

@@ -1280,8 +1356,12 @@ mod tests {
#[test]
fn test_emit_first_n_for_vectorized_group_values() {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Besides these tests, I think it would be good to add .slt tests demonstrating the new metrics appear in EXPLAIN ANALYZE.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Wouldn't that be highly fragile?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

You could use slt:ignore like this

Plan with Metrics LazyMemoryExec: partitions=1, batch_generators=[generate_series: start=0, end=100, batch_size=8192], metrics=[output_rows=101, elapsed_compute=<slt:ignore>, output_bytes=<slt:ignore>]

pub(crate) fn new(metrics: &ExecutionPlanMetricsSet, partition: usize) -> Self {
Self {
time_hashing_grouping_columns: MetricBuilder::new(metrics)
.subset_time("time_hashing_grouping_columns", partition),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is aggregation of per-partition metrics handled elsewhere, or will users need to manually sum across partitions to see total time?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Per partition I think, it's the same as other metrics

@github-actions
Copy link
Copy Markdown

Thank you for your contribution. Unfortunately, this pull request is stale because it has been open 60 days with no activity. Please remove the stale label or comment or this will be closed in 7 days.

@github-actions github-actions Bot added the Stale PR has not had any activity for some time label Apr 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

physical-plan Changes to the physical-plan crate Stale PR has not had any activity for some time

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants