How Oracle’s Hidden Predicate Pushdown Alters SQL Execution and What It Means for Domestic DB Adoption

Recent geopolitical actions that halted Oracle’s sales and services in Russia have reignited interest in domestic database alternatives, highlighting the urgent need for国产化 (localization) of core database systems.

Despite the clear strategic necessity, progress has been slow because domestic products still lag behind foreign leaders in many dimensions, a gap repeatedly discussed at expert meetings.

The author recounts a concrete Oracle behavior observed in a 10053 trace: the optimizer automatically performs a predicate pushdown (FPD) rewrite, adding a function‑based index predicate that changes the SQL semantics and leads to incorrect results. This behavior, initially perceived as a bug, is actually an intentional CBO feature designed to improve plan quality.

To reproduce the case, the author refreshed the buffer cache before each query to eliminate caching effects, then executed two similar queries—one with a condition on t_date_1 (which lacks an index) and another without. The execution plans differed: the second query unexpectedly used an index on a virtual column SUBSTR(t_date_1,1,10) (named IDX_1) that resides on a system‑generated column SYS_NC00005$.

The optimizer’s CBO adds an extra predicate AND SUBSTR("TEST_A"."T_DATE_1",1,8)='20220112' via an FPD rule, causing the plan to select the index and improve performance, while the original WHERE filter remains for row filtering.

This example demonstrates two key strengths of Oracle: the meticulous product engineering that captures rare use‑cases, and a flexible architecture that can introduce new optimizer rules without deep changes to the CBO.

The author also shares a second story about a customer’s database hanging bug. After obtaining a 200 MB SR report from Oracle’s support, he found that only about 10 % of the document contained actual problem analysis; the rest detailed internal diagnostics and improvement discussions, illustrating Oracle’s rigorous post‑mortem process.

Comparing support and product maturity, the author argues that domestic database vendors lag far behind Oracle not only in features but also in after‑sales service, which should be treated as a productivity driver rather than a cost.

He concludes that only by focusing on real customer experiences, learning from detailed failure analyses, and improving product responsiveness can domestic databases close the gap with international leaders.