Skip to content

branch-4.1: [feature](fe) Add partition filter sql block rule (#62196)#63724

Open
CalvinKirs wants to merge 1 commit into
branch-4.1from
4.1-62196
Open

branch-4.1: [feature](fe) Add partition filter sql block rule (#62196)#63724
CalvinKirs wants to merge 1 commit into
branch-4.1from
4.1-62196

Conversation

@CalvinKirs
Copy link
Copy Markdown
Member

Today SQL_BLOCK_RULE can block SQL by regex/sqlHash or by scan scale
thresholds such as
`partition_num`, `tablet_num`, and `cardinality`, but it cannot directly
reject queries that
  scan a partitioned table without using any partition filter.

This PR adds a new scan-based SQL block rule option:
`require_partition_filter`.

When this option is enabled on a rule, Doris rejects scans on supported
partitioned tables if
the query does not contain any usable partition predicate. This helps
prevent accidental full
  partition scans caused by missing partition filters.

The rule is intended for workloads where partition filters are mandatory
for safety or cost
  control.

  ### User-visible behavior

  Users can now create a SQL block rule like this:

  ```sql
  CREATE SQL_BLOCK_RULE require_partition_filter_rule
  PROPERTIES(
      "require_partition_filter" = "true",
      "global" = "true",
      "enable" = "true"
  );

  Or bind it to specific users:

  CREATE SQL_BLOCK_RULE require_partition_filter_rule
  PROPERTIES(
      "require_partition_filter" = "true",
      "global" = "false",
      "enable" = "true"
  );

SET PROPERTY FOR 'test_user' 'sql_block_rules' =
'require_partition_filter_rule';

If a supported partitioned table is scanned without any partition
predicate, Doris returns an
  error like:

sql hits sql block rule: require_partition_filter_rule, missing
partition filter

  ### Scope

  This new rule currently applies to:

  - Partitioned internal tables
  - Partitioned Hive external tables

  This rule does not apply to:

  - Non-partitioned internal tables
  - Non-partitioned Hive tables
  - Iceberg tables
  - Other external table types not wired into this rule yet

  ### Rule semantics

  The new property is:

  - require_partition_filter = true|false

  Behavior:

  - The rule only takes effect when require_partition_filter=true
- For supported partitioned tables, the scan is allowed if the query
hits any partition column
    in partition pruning predicates
  - Filters on non-partition columns do not count
  - The rule applies to scan-producing statements, such as:
      - SELECT
      - INSERT INTO ... SELECT ...
  - EXPLAIN is not blocked

  Examples:

  Blocked:

  SELECT * FROM part_tbl;
  SELECT * FROM part_tbl WHERE non_partition_col = 1;
  INSERT INTO dst SELECT * FROM part_tbl;

  Allowed:

  SELECT * FROM part_tbl WHERE dt = '2026-04-09';
  SELECT * FROM part_tbl WHERE dt = '2026-04-09' AND hh = '10';
  INSERT INTO dst SELECT * FROM part_tbl WHERE dt = '2026-04-09';

  ### Compatibility and validation

require_partition_filter is treated as a scan-based SQL block condition.

  It can be used together with existing scan-based limits such as:

  - partition_num
  - tablet_num
  - cardinality

  It cannot be mixed with text-based block conditions such as:

  - sql
  - sqlHash
@CalvinKirs CalvinKirs requested a review from yiguolei as a code owner May 27, 2026 06:50
@hello-stephen
Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@CalvinKirs
Copy link
Copy Markdown
Member Author

run buildall

@hello-stephen
Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 63.35% (121/191) 🎉
Increment coverage report
Complete coverage report

@hello-stephen
Copy link
Copy Markdown
Contributor

FE Regression Coverage Report

Increment line coverage 60.31% (117/194) 🎉
Increment coverage report
Complete coverage report

@CalvinKirs
Copy link
Copy Markdown
Member Author

run feut

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants