aminghadersohi commented on PR #45681: URL: https://github.com/apache/superset/pull/45681#issuecomment-6387078443
Acceptance run at e0dc5c97535e970d8de7d02187be203ebad8bd0e against the merge-base 3c9f08d1b3920c91c743bd376ea2cd6b36d3e01c (base = the three changed files checked out from the merge-base, same stack). **Setup:** docker-compose-light, Postgres 17 as the analytic DB (60k-row table), one dashboard per dataset with 10 charts and 3 cascading native filters. Connections counted twice and the counts agree exactly: a SQLAlchemy `connect` listener with call stacks, and Postgres `log_connections` (`connection authorized ... database=<analytic db>`). Users: admin, a Gamma user with RLS rules on the underlying physical tables, and an embedded guest token. Traffic: the chart-data requests a dashboard load sends, plus a Playwright run of the real UI (load, reload, cascade-select the three filters, open Explore). **Connections per dashboard load (13 chart-data requests), base → head** | Dataset | cold | warm (all cache hits) | force refresh | |---|---|---|---| | virtual, schema set | 33 → 10 | 13 → 0 | 39 → 13 | | virtual, schema set, Gamma + RLS | 33 → 10 | 13 → 0 | 39 → 13 | | virtual, schema set, embedded guest | 30 → 10 | 10 → 0 | – | | virtual, Jinja-templated SQL | 46 → 10 | 26 → 0 | 52 → 13 | | virtual, impersonation on | 33 → 10 | 13 → 0 | 39 → 13 | | physical | 10 → 10 | 0 → 0 | 13 → 13 | | virtual, schema NULL | 33 → 33 | 13 → 13 | 39 → 39 | - Cache hits on a virtual dataset with a schema open no analytic connection at head; an uncached request opens one (the query). At base it was three per uncached request and one per cache hit (two with Jinja). - Across the whole run Postgres logged 2480 logins at base and 1115 at head. Physical, schema-NULL and SQL Lab counts are unchanged. - The browser run matches: reload 13 → 0, filter cascade 33 → 10, Explore 3 → 1. **Results unchanged:** 1,434 base/head request pairs have the same status, cache key, SQL text, rows and `is_cached`. That covers admin, Gamma with RLS and guest, all variants above, SQL Lab sync, and query-backed charts (same `Query` ids on both builds, schema set and NULL). The RLS predicates appear in the same SQL at both. Schema NULL still falls back to the database default schema. **Default-schema lookup raising:** at base every virtual-dataset chart fails with a 500. At head, schema-set virtual datasets (plain and Jinja) and schema-set query-backed charts return the same data. Schema-NULL ones still fail because they need the lookup. **Timing, with a simulated 0.7 s warehouse login per connection:** warm load of the schema-set virtual dashboard 2.5–2.8 s → 0.3–0.6 s (median cache-hit request 0.88 s → 0.15 s), the same as the physical dashboard. Cold load 8.5 s → 3.2 s. **Pre-existing, outside this diff (not regressions, measured at head):** - `find_datasets` (superset/utils/rls.py:222) still calls `get_default_schema` once per cache hit when the virtual SQL reads a table whose physical dataset is registered with schema NULL. This PR halves it (26 → 13 per warm load) but does not remove it. - `get_default_catalog()` (superset/utils/rls.py:317 and :90, superset/security/manager.py:5179) runs once or more per request. It opens no connection on Postgres or Snowflake, but per the engine specs it does on Databricks without `connect_args.catalog`, Doris without a catalog in the URI, and BigQuery/Datastore without a project in the URI. That part comes from reading the code; I did not measure it. **Not covered:** a real Snowflake connection (counts are real Postgres logins, and the login cost is simulated), async SQL Lab (no Celery in the light stack), and `CACHE_IMPERSONATION` on. screenshots: n/a (not a visual change) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
