You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
1 - Avoid full table mapping in renderer replace_table(s) calls #6017
_resolve_table resolves one table but passes the full physical + view mapping into exp.replace_tables, which re-parses every mapping key.
The full mapping today is passed to the exp.replace_tables and is:
{
**self._to_table_mapping((snapshots or {}).values(), deployability_index),
**(table_mapping or {}),
}
Look up this table’s entry (table_mapping overrides physical) and pass a one-entry dict into exp.replace_tables.
Keying must match how replace_tables normalizes names (quoting/case), or we miss. Either normalize this one name the same way before lookup, or pass the one pair through and let replace_tables normalize that single key.
Issue with _resolve_tables:
We pass in expression and create the table_mapping. Problem is, we don't check if the expression contains a table node, which is what's required for any of the downstream code to be useful.
So basically:
if not snapshots and not table_mapping and not expand:
return expression
if not expression.find(exp.Table): <----- NEW
return expression
expression = expression.copy()
This skips the execution entirely for expressions that only contain virtual or session properties.
I tested the change against our production-backed monorepo project to understand whether the improvement translated beyond the focused unit tests.
The targeted benchmark confirms the optimization works: repeated resolution against 3,132 production snapshots was substantially faster, and the rendered SQL remained identical. However, a real environment promotion showed no measurable improvement in the virtual-layer stage:
Baseline: 1.782s
Patched: 1.790s
A broader render-only run across 1,775 promoted models produced the same conclusion. Most properties in the real project are plain strings and do not exercise the expensive expression-resolution path often enough to affect overall plan performance.
The change appears correct, but the practical benefit is too narrow to justify carrying the additional logic without a real workload demonstrating an end-to-end improvement. I’m going to close this PR for now. We can revisit it if we find a project where table-containing property expressions materially slow promotion.
Activity
mday-io commentedon Sep 21, 2026
Adding the same comment I posted on #6068