Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Done
Description
Development tasks:
MDEV-406 ANALYZE $stmt
MDEV-6388 ANALYZE $stmt output in the slow query log
MDEV-6382 ANALYZE $stmt and security
MDEV-6109 EXPLAIN JSON
Need to check also for
- Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?)
- Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs)
<spetrunia>: there was a problem with printing table names in ANALYZE
<spetrunia>: it was resolved
<spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW
<spetrunia>: then run EXPLAIN UPDATE/DELETE on it
<spetrunia>: then run ANALYZE UPDATE/DELETE
<spetrunia>: and check that the ouptuts match
<spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW)
<spetrunia>: and not table names
<spetrunia>: or was it vice versa
<spetrunia>: anyhow, it was not what EXPLAIN printed
<spetrunia>: I don't think it's needed to spend much time on this..
<spetrunia>: create a test case; let view definitions use table aliases
<spetrunia>: which are different from the table names
<spetrunia>: if it works, ok - PS (binary protocol)
- Get testcases for
MDEV-6382 - Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log?
Attachments
Issue Links
- is blocked by
-
MDEV-7024 Assertion `! is_set()' failed in Diagnostics_area::set_eof_status on executing ANALYZE SELECT via PS
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Confirmed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
(5 relates to)
Activity
| Fix Version/s | 10.1.1 [ 16801 ] |
| Labels | analyze-stmt |
| Description |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) * PS (binary protocol) |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) * PS (binary protocol) * Get testcases for |
| Description |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) * PS (binary protocol) * Get testcases for |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) * PS (binary protocol) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? |
| Assignee | Sergei Petrunia [ psergey ] | Elena Stepanova [ elenst ] |
| Fix Version/s | 10.1 [ 16100 ] | |
| Fix Version/s | 10.1.1 [ 16801 ] |
| Parent |
|
|
| Issue Type | Task [ 3 ] | Technical task [ 7 ] |
| Affects Version/s | 10.1.0 [ 12200 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Description |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) * PS (binary protocol) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) {quote} <spetrunia>: there was a problem with printing table names in ANALYZE <spetrunia>: it was resolved <spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW <spetrunia>: then run EXPLAIN UPDATE/DELETE on it <spetrunia>: then run ANALYZE UPDATE/DELETE <spetrunia>: and check that the ouptuts match <spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW) <spetrunia>: and not table names <spetrunia>: or was it vice versa <spetrunia>: anyhow, it was not what EXPLAIN printed <spetrunia>: I don't think it's needed to spend much time on this.. <spetrunia>: create a test case; let view definitions use table aliases <spetrunia>: which are different from the table names <spetrunia>: if it works, ok {quote} * PS (binary protocol) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? |
| Description |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) {quote} <spetrunia>: there was a problem with printing table names in ANALYZE <spetrunia>: it was resolved <spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW <spetrunia>: then run EXPLAIN UPDATE/DELETE on it <spetrunia>: then run ANALYZE UPDATE/DELETE <spetrunia>: and check that the ouptuts match <spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW) <spetrunia>: and not table names <spetrunia>: or was it vice versa <spetrunia>: anyhow, it was not what EXPLAIN printed <spetrunia>: I don't think it's needed to spend much time on this.. <spetrunia>: create a test case; let view definitions use table aliases <spetrunia>: which are different from the table names <spetrunia>: if it works, ok {quote} * PS (binary protocol) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) (/) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) (/) {quote} <spetrunia>: there was a problem with printing table names in ANALYZE <spetrunia>: it was resolved <spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW <spetrunia>: then run EXPLAIN UPDATE/DELETE on it <spetrunia>: then run ANALYZE UPDATE/DELETE <spetrunia>: and check that the ouptuts match <spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW) <spetrunia>: and not table names <spetrunia>: or was it vice versa <spetrunia>: anyhow, it was not what EXPLAIN printed <spetrunia>: I don't think it's needed to spend much time on this.. <spetrunia>: create a test case; let view definitions use table aliases <spetrunia>: which are different from the table names <spetrunia>: if it works, ok {quote} * PS (binary protocol) (x) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? (/) |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Fix Version/s | 10.1.4 [ 18400 ] | |
| Fix Version/s | 10.1 [ 16100 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Fix Version/s | 10.1 [ 16100 ] | |
| Fix Version/s | 10.1.4 [ 18400 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Workflow | MariaDB v2 [ 49701 ] | MariaDB v3 [ 64530 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Description |
Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) (/) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) (/) {quote} <spetrunia>: there was a problem with printing table names in ANALYZE <spetrunia>: it was resolved <spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW <spetrunia>: then run EXPLAIN UPDATE/DELETE on it <spetrunia>: then run ANALYZE UPDATE/DELETE <spetrunia>: and check that the ouptuts match <spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW) <spetrunia>: and not table names <spetrunia>: or was it vice versa <spetrunia>: anyhow, it was not what EXPLAIN printed <spetrunia>: I don't think it's needed to spend much time on this.. <spetrunia>: create a test case; let view definitions use table aliases <spetrunia>: which are different from the table names <spetrunia>: if it works, ok {quote} * PS (binary protocol) (x) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? (/) |
Development tasks: Need to check also for * Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?) (/) * Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs) (/) {quote} <spetrunia>: there was a problem with printing table names in ANALYZE <spetrunia>: it was resolved <spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW <spetrunia>: then run EXPLAIN UPDATE/DELETE on it <spetrunia>: then run ANALYZE UPDATE/DELETE <spetrunia>: and check that the ouptuts match <spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW) <spetrunia>: and not table names <spetrunia>: or was it vice versa <spetrunia>: anyhow, it was not what EXPLAIN printed <spetrunia>: I don't think it's needed to spend much time on this.. <spetrunia>: create a test case; let view definitions use table aliases <spetrunia>: which are different from the table names <spetrunia>: if it works, ok {quote} * PS (binary protocol) (x) * Get testcases for * Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log? (/) |
| Summary | More QA for ANALYZE stmt | More QA for ANALYZE stmt and JSON |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Priority | Major [ 3 ] | Minor [ 4 ] |
| Assignee | Elena Stepanova [ elenst ] | Alice Sherepa [ alice ] |
| Summary | More QA for ANALYZE stmt and JSON | More testing for ANALYZE stmt and JSON |
| Parent |
|
|
| Affects Version/s | 10.1.0 [ 12200 ] | |
| Issue Type | Technical task [ 7 ] | Task [ 3 ] |
| Assignee | Alice Sherepa [ alice ] | Elena Stepanova [ elenst ] |
| Workflow | MariaDB v3 [ 64530 ] | MariaDB v4 [ 131636 ] |
| Component/s | Tests [ 10800 ] | |
| Fix Version/s | N/A [ 14700 ] | |
| Resolution | Done [ 10200 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Fix Version/s | 10.1 [ 16100 ] |