Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 12.2.2
-
Related to performance
Description
id is the primary key, so SELECT DISTINCT id FROM t is semantically equivalent to SELECT id FROM t. However, MariaDB does not eliminate the redundant DISTINCT inside a derived table. The DISTINCT version is materialized and runs significantly slower.
How to repeat
DROP DATABASE IF EXISTS perf_distinct_big;
|
CREATE DATABASE perf_distinct_big;
|
USE perf_distinct_big;
|
|
|
CREATE TABLE t (
|
id INT PRIMARY KEY,
|
pad CHAR(100) |
);
|
|
|
CREATE TABLE d(n INT);
|
INSERT INTO d VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); |
|
|
INSERT INTO t
|
SELECT a.n + 10*b.n + 100*c.n + 1000*d1.n + 10000*e.n + 100000*f.n, |
REPEAT('x', 100) |
FROM d AS a
|
JOIN d AS b
|
JOIN d AS c
|
JOIN d AS d1
|
JOIN d AS e
|
JOIN d AS f;
|
|
|
EXPLAIN
|
SELECT COUNT(*)
|
FROM (
|
SELECT id FROM t
|
) AS s;
|
|
|
EXPLAIN
|
SELECT COUNT(*)
|
FROM (
|
SELECT DISTINCT id FROM t
|
) AS s;
|
|
|
SET profiling = 1; |
|
|
SELECT SQL_NO_CACHE COUNT(*)
|
FROM (
|
SELECT id FROM t
|
) AS s;
|
|
|
SELECT SQL_NO_CACHE COUNT(*)
|
FROM (
|
SELECT DISTINCT id FROM t
|
) AS s;
|
|
|
SHOW PROFILES;
|
Observed on 12.2.2-MariaDB-ubu2404:
SELECT id: 0.18073567s |
SELECT DISTINCT id: 0.44433452s |
Expected:
The optimizer should remove DISTINCT because id is a primary key and already unique.
Actual:
The DISTINCT derived table is materialized and takes about 2.5x longer.
Attachments
Issue Links
- relates to
-
MDEV-9964 Optimize DISTINCT away when it is not needed
-
- Open
-
-
MDEV-40474 Redundant outer DISTINCT creates an additional temporary table above EXCEPT in MariaDB
-
- Confirmed
-