CockroachDB adds s390x support and selective optimizer controls

The platform announcement in CockroachDB 25.3.2 is brief and specific. Released on September 22, it introduces support for running CockroachDB on s390x, with production binaries delivered through IBM Passport Advantage. That distribution route is part of the announcement, rather than an incidental detail to replace with an assumed public download URL.

For deployments outside that platform, the same patch contains a more directly applicable control. A new session variable can disable named optimizer rules. Another setting changes which row estimate determines whether a scan should force distributed execution. Together, they expose two distinct stages in the path from a SQL query to work running across nodes.

I accept CockroachDB's distributed execution costs when they serve its consistency and placement model. Unnecessary distribution is a different concern. Having a way to identify which planning decision introduced that work is useful even when the database's broader architecture is the reason for choosing it.

A rule controls which alternatives the optimizer considers

The new disable_optimizer_rules session variable accepts a comma-separated list of rule names. The release notes describe its purpose as avoiding rules known to create suboptimal plans for particular queries. It is a selective override, with the selection expressed in optimizer terminology rather than in an application-level description such as making a query faster.

The implementation patch makes the effect concrete. Its test creates a table with an index on b, then explains a query constrained by b = 1. With the default setting, the plan uses the secondary index and an index join. Disabling GenerateConstrainedScans changes that example to a full primary-index scan with a filter.

That example is deliberately a demonstration of control, not a tuning recommendation. Removing the rule can eliminate an efficient access path. A rule that produces an undesirable alternative in one situation can produce the useful alternative in another. The session variable removes a transformation opportunity rather than specifying the complete replacement plan.

The patch's tests also establish how input is interpreted. Names are case-insensitive, surrounding spaces are trimmed, and an unknown rule produces a notice and is ignored. A misspelled name therefore does not necessarily fail the SQL statement. Inspecting the active value matters when establishing whether an attempted override actually took effect.

The following statements use the inspection and reset forms covered by the implementation tests. They show the session's current selection and restore its default behavior without choosing a rule to suppress:

SHOW disable_optimizer_rules;
RESET disable_optimizer_rules;

The implementation also incorporates the disabled-rule selection into checks for stale optimizer state. Changing the selection is intended to affect planning, rather than leaving an otherwise reusable optimizer memo unaware of the new restriction. That detail matters because a setting which influences candidate generation must participate in the machinery deciding whether previous planning work remains applicable.

Distribution uses an estimate of how much work remains

The patch also adds use_soft_limit_for_distribute_scan, defaulting to false. Its release note traces the behavior to a change in version 25.1. Under distsql=auto, constrained scans estimated to read at least 10,000 rows could force distributed execution, with the threshold controlled by distribute_scan_row_count_threshold.

A scan with a soft limit could still be judged using the full estimate. The release illustrates the difference with an estimated range from one hundred to ten thousand rows. Using the upper estimate could distribute a query unnecessarily and increase latency. Enabling the new setting lets that decision use the soft row estimate instead.

This is a different intervention from disabling a transformation rule. One affects which plan alternatives are generated. The other affects the physical decision about distributing a scan based on its estimated work. Neither specifies an entire execution plan, and the controls should not be interpreted as interchangeable ways to request local execution. Treating both as generic optimizer switches loses the mechanism needed to explain their results.

The cost-based optimizer documentation identifies cardinality estimates as a major influence on plan quality. Statistics inform those estimates, while planning rules and distribution heuristics determine how estimates are used. An inaccurate estimate and an inappropriate use of a reasonable estimate can therefore produce similar symptoms through different causes.

The release contains several independent compatibility boundaries

Support for s390x establishes a platform option with a named production distribution channel. It does not establish that a particular workload benefits from the optimizer settings, or that a query problem requires a platform change. These are independent additions shipped in the same patch.

I find the optimizer changes valuable because they expose narrow decisions that can be discussed precisely. A plan investigation can distinguish a missing constrained-scan alternative from a distribution choice driven by a soft limit. That leaves a more useful explanation than attributing every latency change to the fact that CockroachDB runs across multiple nodes.