Normalize machine names: drop redundant cloud prefix, normalize T-shirt sizes#881
Merged
Conversation
…rt sizes For cloud-service results whose .machine value contains a memory size (GB / GiB) or a T-shirt size (XS / S / M / L / XL / NXL etc), drop the redundant cloud-name prefix so the dashboard groups runs by the actual size rather than the (system, machine) tuple. The system field on each entry already carries the cloud name; repeating it inside .machine just bloats the X axis. Also normalize T-shirt sizing variants to their letter form: Small → S, Medium → M, Large → L, X-Small → XS, X-Large → XL, 2X-Small → 2XS, 2X-Large → 2XL, 3X-Large → 3XL, 4X-Large → 4XL, 5X-Large → 5XL. Affected systems: AlloyDB, ByteHouse, CHYT, ClickHouse Cloud (every aws/azure/gcp tier), CrunchyBridge, Databricks, Hydra, Snowflake, Supabase, Tablespace, Timescale Cloud, pgpro_tam. Bare-metal hardware descriptions (CPU model + RAM, "AWS c5.metal 100GB", etc) are left unchanged — the rule applies to managed-cloud machine labels only. Aurora's "16acu", Hologres' "16 CU", Redshift's "ra3.4xlarge", and SingleStore's "S2"/"S24" don't match the GB or T-shirt-size pattern and are also left alone. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Convert "<digits><space?>GB" → "<digits>GiB" in cloud-service machine names. Where the value also carries an "<N> vCPU " prefix in front of the GB amount, drop that prefix — the GiB tier already conveys the size, so "8 vCPU 64 GB" simplifies to "64GiB". Examples: - "8 vCPU 64 GB" (AlloyDB) → "64GiB" - "10 vCPU 40GB" (CHYT) → "40GiB" - "720GB" (CHYT) → "720GiB" - "Analytics-256GB" (Crunchy Bridge) → "Analytics-256GiB" - "L1 - 16CPU 32GB" (Tablespace) → "L1 - 16CPU 32GiB" (16CPU is not "vCPU" so it stays) - "8 vCPU 32GB" (Timescale ☁️) → "32GiB" - "16 vCPU 32GB" / "30 vCPU 480GB" (pgpro_tam) → "32GiB" / "480GiB" - "64 vCPU 256GB" (YDB) → "256GiB" Bare-metal hardware descriptions in hardware/, versions/, gravitons/ (e.g. "AWS c5.metal 100GB", "Linode 16GB", "Steam Deck 512 GB", "AMD EPYC 3.2 GHz, Micron 5100 MAX 960 GB") are left alone. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
For cloud-service result files whose
.machinevalue contains amemory size (GB / GiB) or a T-shirt size (XS / S / M / L / XL / NXL),
drop the redundant cloud-name prefix. The
systemfield alreadycarries the cloud name, so repeating it inside
.machinebloats thedashboard's machine axis. Examples:
AlloyDB: 8 vCPU 64 GB→8 vCPU 64 GBByteHouse: XS→XSClickHouse ☁️: 120GiB→120GiBDatabricks: 2X-Large→2XL(also normalized; see below)Hydra: XL→XLSnowflake: 2XL→2XLSupabase: 4XL→4XLTablespace: L1 - 16CPU 32GB→L1 - 16CPU 32GBTimescale ☁️: 16 vCPU 64GB→16 vCPU 64GBpgpro_tam: 16 vCPU 32GB→16 vCPU 32GBAlso normalize T-shirt sizing variants to their letter form:
Small→S,Medium→M,Large→LX-Small→XS,X-Large→XL2X-Small→2XS,2X-Large→2XL,3X-Large→3XL,4X-Large→4XL,5X-Large→5XLWhat's left alone
2x Intel Xeon ...,AMD EPYC ...,AWS c5.metal 100GB,Steam Deck 512 GB, etc.)— those are CPU/instance descriptions, not managed-cloud labels.
Aurora: 16acu(Aurora Capacity Unit, no GB)Hologres: 16 CU(Compute Unit, no GB)Redshift: ra3.4xlargeand similar (xlargeis part of aninstance type name, not a T-shirt size)
SingleStore: S2/SingleStore: S24(Sn isn't the same as theXS/S/M/L/XL/NXL convention)
Motherduck: jumbo/mega/pulse/standard(tier names butnot the T-shirt convention either)
Test plan
ClickHouse Cloud, Databricks, Snowflake group runs by their
tier/size only, with no redundant cloud-name repetition on the
machine axis.
🤖 Generated with Claude Code