kokhlo commented on issue #44241: URL: https://github.com/apache/superset/issues/44241#issuecomment-5666545357
Confirmed on current `master` in `superset/connectors/sqla/utils.py`, `get_columns_description` (the `cursor.execute(mutated_query)` at line 196 immediately followed by `db_engine_spec.execute(cursor, mutated_query, database)`). The first statement run is pure discarded work: `BaseEngineSpec.execute` itself dispatches to `cursor.execute(query)` (see `superset/db_engine_specs/base.py`), so the same statement is sent to the database twice back to back, and `fetch_data` only ever reads the cursor left by the second run. Besides doubling the cost of the metadata probe on the dataset's SQL, it also defeats the admin's expectation of a per-statement cap (`max_statement_time` and friends): two identical executions means the ceiling for the probe is 2x the configured statement timeout, exactly as reported. Root cause looks like a leftover from before `db_engine_spec.execute` took over statement dispatch — the `TODO(villebro)` right above the block hints the same path was refactored for `sql_lab.py`, where only the spec-level `execute` call remains. Plan: - remove the redundant `cursor.execute(mutated_query)` line so the probe runs the statement exactly once, matching the `sql_lab.py` pattern; - add a regression test with a stub cursor/engine spec asserting the statement is executed exactly once per probe (and that the clickhouse-style `get_column_description_retry_sql` path is unaffected); - keep `apply_limit_to_sql` behavior untouched here — the wrap-vs-append LIMIT point from the report deserves its own discussion, since it changes the query shape for every engine. PR within the hour. -- 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]
