Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
Description
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does.
Difference from MySQL's EXPLAIN FORMAT=JSON
We don't want to copy MySQL 5.6:
From the user point of view:
- 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases)
- I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document.
- 5.6 output format doesn't allow to display some info we want to display
- 5.6's output format has legacy of tabular output format in many places
- MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces
Currently supported
- Basic SELECTs
- Table access methods
- full table/index scans
- range access
- index_merge access
- I_S read optimizations
- "Using where" (attached_condition)
- rows and 'filtered' columns
- Index Condition Pushdown ('index_condition')
- UNIONs (incomplete)
- Item-based subqueries (incomplete)
- Basic join buffering
- Single-table UPDATE/DELETE
- Derived tables
- Non-merged semi-joins (JTBMs)
- [Merged] Semi-joins: SJ-Materialization
- [Merged] Semi-joins: FirstMatch, DuplicateElimination, LooseScan
Not yet supported (important)
- ORDER BY/GROUP BY/ DISTINCT handling – as agreed won't be ready before 10.1.2
Not yet supported (less important)
- Subquery cache feature
- Advanced join buffering (display MRR as a special kind of scan)
Attachments
Issue Links
- relates to
-
MDEV-6995 EXPLAIN JSON and ORDER BY, GROUP BY, etc
-
- Open
-
-
MDEV-7248 EXPLAIN FORMAT=JSON: Better output
-
- Open
-
-
MDEV-7264 Assertion `0' failed in subselect_engine::get_identifier() on EXPLAIN FORMAT=JSON
-
- Closed
-
-
MDEV-7265 Assertion `0' failed in Explain_table_access::tag_to_json(Json_writer*, explain_extra_tag)
-
- Closed
-
-
MDEV-7266 Assertion `!element_started' failed in Json_writer& Json_writer::add_member(const char*)
-
- Closed
-
-
MDEV-7267 Server crashes in Item_field::print on ANALYZE FORMAT=JSON
-
- Closed
-
- links to
Activity
Field | Original Value | New Value |
---|---|---|
Priority | Major [ 3 ] | Critical [ 2 ] |
Labels | optimizer |
Assignee | Sergei Petrunia [ psergey ] |
Workflow | defaullt [ 38925 ] | MariaDB v2 [ 42477 ] |
Priority | Critical [ 2 ] | Major [ 3 ] |
Priority | Major [ 3 ] | Critical [ 2 ] |
Fix Version/s | 10.1.1 [ 16100 ] | |
Fix Version/s | 10.1.0 [ 12200 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Description | merge EXPLAIN JSON from 5.6 |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * range access * index_merge access * attached_condition * Index Condition Pushdown ('attached_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * range access * index_merge access * attached_condition * Index Condition Pushdown ('attached_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.5's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering * Semi-joins |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering * Semi-joins |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering * Semi-joins |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Subqueries (incomplete) h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Join buffering * Semi-joins |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? * |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering h2. Not yet supported * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? * |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? h2. Not yet supported (less important) * Subquery cache feature |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? h2. Not yet supported (less important) * Subquery cache feature |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? * Single-table UPDATE/DELETE/INSERT h2. Not yet supported (less important) * Subquery cache feature |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? * Single-table UPDATE/DELETE/INSERT h2. Not yet supported (less important) * Subquery cache feature |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? h2. Not yet supported (less important) * Subquery cache feature |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins * derived tables? h2. Not yet supported (less important) * Subquery cache feature |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins h2. Not yet supported (less important) * Subquery cache feature |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * Semi-joins h2. Not yet supported (less important) * Subquery cache feature |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables * Non-merged semi-joins (JTBMs) * [Merged] Semi-joins: SJ-Materialization h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * [Merged] Semi-joins: FirstMatch, DuplicateElimination, LooseScan h2. Not yet supported (less important) * Subquery cache feature |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables * Non-merged semi-joins (JTBMs) * [Merged] Semi-joins: SJ-Materialization h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * Advanced join buffering (display MRR as a special kind of scan) * [Merged] Semi-joins: FirstMatch, DuplicateElimination, LooseScan h2. Not yet supported (less important) * Subquery cache feature |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables * Non-merged semi-joins (JTBMs) * [Merged] Semi-joins: SJ-Materialization h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * [Merged] Semi-joins: FirstMatch, DuplicateElimination, LooseScan h2. Not yet supported (less important) * Subquery cache feature * Advanced join buffering (display MRR as a special kind of scan) |
Remote Link | This issue links to "MySQL Bug: "EXPLAIN FORMAT=json output not documented." (Web Link)" [ 21606 ] |
Description |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables * Non-merged semi-joins (JTBMs) * [Merged] Semi-joins: SJ-Materialization h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling * [Merged] Semi-joins: FirstMatch, DuplicateElimination, LooseScan h2. Not yet supported (less important) * Subquery cache feature * Advanced join buffering (display MRR as a special kind of scan) |
Support EXPLAIN FORMAT=JSON like MySQL 5.6 does. h2. Difference from MySQL's EXPLAIN FORMAT=JSON We don't want to copy MySQL 5.6: From the user point of view: * 5.6 output format is not documented and unstable (even MySQL Workbench fails to parse it in some cases) ** I don't expect that any 3rd party is able to parse it, other than relying that it's a well-formed JSON document. * 5.6 output format doesn't allow to display some info we want to display * 5.6's output format has legacy of tabular output format in many places * MariaDB has more optimizer features, so we will have to produce output that 5.6 never produces h2. Currently supported * Basic SELECTs * Table access methods ** full table/index scans ** range access ** index_merge access ** I_S read optimizations * "Using where" (attached_condition) * rows and 'filtered' columns * Index Condition Pushdown ('index_condition') * UNIONs (incomplete) * Item-based subqueries (incomplete) * Basic join buffering * Single-table UPDATE/DELETE * Derived tables * Non-merged semi-joins (JTBMs) * [Merged] Semi-joins: SJ-Materialization * [Merged] Semi-joins: FirstMatch, DuplicateElimination, LooseScan h2. Not yet supported (important) * ORDER BY/GROUP BY/ DISTINCT handling -- as agreed won't be ready before 10.1.2 h2. Not yet supported (less important) * Subquery cache feature * Advanced join buffering (display MRR as a special kind of scan) |
Component/s | Optimizer [ 10200 ] | |
Fix Version/s | 10.1.2 [ 15801 ] | |
Fix Version/s | 10.1 [ 16100 ] | |
Resolution | Fixed [ 1 ] | |
Status | In Progress [ 3 ] | Closed [ 6 ] |
Workflow | MariaDB v2 [ 42477 ] | MariaDB v3 [ 64142 ] |
Workflow | MariaDB v3 [ 64142 ] | MariaDB v4 [ 132319 ] |