When a query against a table with a row filter runs slowly, the first thing an engineer wants to know is whether the time went into the policy or into the query. On Spark Connect, the quickest way to look from code is df.executionInfo.metrics, the execution details a DataFrame carries after its query runs (PySpark reference). The Databricks Runtime 19 update of 19 October 2026 hides the internal operators and metrics tied to row filters and column masks from that view, including its text form, while the boundary of the protected part of the plan keeps its own metrics and query results don't change.
The second half of a change that started in August #
We'd read this alongside the 10 August 2026 entry on the same page, which stopped query plans from exposing row filter and column mask policy logic unless the user holds the INSPECT_POLICY_EXECUTION metastore privilege. Plans were one window into a policy and execution metrics were the other, and Runtime 19 has now shut both. We think that's the right call. A policy exists to decide what a reader may see, and counts or timings from operators inside it describe data the reader was filtered away from. For plans, we'd keep INSPECT_POLICY_EXECUTION with the small group that writes and reviews policy functions, the same people who own them in the repository as the Unity Catalog chapter recommends, and away from analysts who only query the tables.
The October entry names no privilege that brings the hidden metrics back, so we wouldn't plan on one.
What we'd still tune with #
Losing the inside of the policy may cost less than it sounds, because Databricks' performance guide for row filter and column mask policies calls predicate pushdown the most common source of performance issues with protected tables. A SecureView barrier sits on every protected table, and a predicate that calls a function or forces an implicit cast stays above it, which can block partition pruning and liquid clustering and force a full scan. That happens even when the policy resolves to true for everyone. The guide's own example is WHERE date_format(o_orderdate, 'yyyy-MM-dd') = '1995-07-29', which moves above the barrier, against WHERE o_orderdate = '1995-07-29', which still reaches the scan.
That's a question about where a predicate lands relative to the policy boundary, and the release note says only that the boundary of the protected portion of the plan stays visible. The tuning loop we'd run on a slow protected query stays the same. We'd check whether the filter reached the scan, rewrite it as a plain comparison on the partition or clustering column if it didn't, swap error-prone expressions such as / for try_divide, and use the policy's EXCEPT clause for exempt groups, which the guide says removes the barrier for them entirely. The UDF side of the work is design-time, in the policy function itself, and the security chapter already argues for computing an expensive decision into a column in the pipeline.
Who has something to change #
Anything that parses executionInfo.metrics. It's a Spark Connect API, and Databricks lists where Spark Connect runs: serverless compute, standard compute notebooks, Databricks Connect and Lakeflow pipelines with environment versions. A home-grown profiler that logs per-operator row counts to a table, or a test that asserts on a specific operator's metrics, will see fewer operators on protected tables and may need updating. Clusters on Runtime 19 pick the change up when they restart, and Databricks stages releases, so a workspace can lag the date by a few days.