Hi Judit 👋 Thanks for your patience on this, and for the thorough proposal on the GitHub issue. We really appreciate the time you put into detailing the problem and the proposed solution. We reviewed the

ignore_dimensions

approach internally and wanted to share where we landed. Recommended workaround For metrics where the numerator and denominator need different levels of aggregation, we recommend pre-computing the coarser-grain metric in your dbt model. The pattern is: 1. Compute the denominator (e.g., total customers per region) in a separate CTE, independently of the finer-grain dimensions 2. Join it back to the detail-level data 3. Use a

type: max

metric in Lightdash to surface the pre-computed value 4. Define a

type: number

metric for the final percentage calculation We've documented this pattern with a full working example here: https://docs.lightdash.com/references/metrics#level-of-detail-metrics Why we don't recommend moving forward with an

ignore_dimensions

contribution We appreciate the offer to contribute a PR, but after discussion with the engineering team we have some concerns with this approach: • SQL complexity: Generating separate CTEs per metric with different

ignore_dimensions

lists, then cross-joining or left-joining them back, adds significant complexity to the generated SQL. With many metrics and dimensions in play, the queries become harder to debug and optimize. • Semantic layer philosophy: Lightdash's semantic layer is designed to define what metrics mean, not how queries should be structured.

ignore_dimensions

embeds query-time behavior into metric definitions, which blurs that boundary. • dbt is well-suited for this: The dbt transformation layer is purpose-built for this kind of data reshaping. Pre-computing values at the right grain in dbt keeps queries simple, performant, and easy to debug. We understand the concern about table size explosion with cross joins. The pre-computed CTE approach avoids that entirely since it only computes the aggregate once per group, not for every dimension combination. We're keeping the GitHub issue open and will continue to evaluate as the product evolves. Happy to help if you have any questions about implementing the workaround!

Many thanks, Tori! 🙌 Understood! Unfortunately, we already tested that approach during development, and it only shifts the problem from a cross join to an equally expensive computation of CTEs with all combinations of user dimensions and date ranges, plus adds overhead to the UX, and doesn't align with the dynamic experience we want to provide to our stakeholders. We'll try to stick with the cross join until the data grows too large to sustain it. Let us know if you reconsider the issue at some point. We'd be happy to contribute, as this is becoming a major pain point for us with our growing data.

Thanks for sharing that context, Judit! I appreciate you testing the workaround thoroughly. We understand it doesn't fully solve the problem for your use case. We'll keep the GitHub issue open and will circle back if our approach evolves. If you'd like, we'd also be happy to set up a call to walk through your setup and see if there are any other options we might be missing. Just let us know 🙂