Plans for 5.6

OpenGIS compliance

• create required tables: GeometryTables, GeometryColumns, related views.
• stored procedure AddGeometryColumn
• prefill the spatial_ref_sys table.

Add possible III-rd coordinate (Attitude).

• Distance3D, related optimization.

• Precise math coordinates instead of DOUBLE-s.

GIS-Optimizer

• optimize simple queries with Intersects(), Within, Distance()<X
• add Distance_sphere() and the related optimization.

Online operations

• Extension to bigger datatype (var)char(n) (n+x)
• numerique (datatype >)
• Extend ENUM done need more visibility
• Alter comment
• Online Add and drop index
• Online OPTIMIZE
• ANALYSE

COMPATIBILITY & USABILITY

• Date & time embedded timezone
• IPV6 native type
• Functions
• Datatype
• Extended timestamp > 2038
• 1M tables Information schema
• 1M users requirements
• mysql.* in any engine
• LOG tables in a log_schema schema
• User Ldap Authentification like Drizzle
• Link against openssl
• Query logging tracking per user
• Flush and reload variables from my.cnf

Replication

• Replication filters, like --replicate-do-db and friends, need to be possible to change dynamically, without having to restart the server. Having to stop the slave should ideally also not be needed, but is less of a problem.

• Transactional storage of slave state, rather than file-based master.info and relay-log.info . So the slave can recover consistently after a crash.

• Global transaction ID, so the slave state becomes recoverable, and facilitate automatic moving a slave to a new master across multi-level hierarchies.

• Support in global transaction ID for master_pos_wait()

• Hooks around rotation of the binlog, so user can configure shell commands when a new log is started and when it is ended. The command must be run asynchroneously, and get the old and new log file name as arguments.

• Sending of heartbeats from master to slaves, so slaves starting up can know in finite time where the master is.

• Replication APIs, as per MWL#107
  • Most important MWL#120 and MWL#133, for obtaining and applying events.
  • Then a mechanism for prioritizing transactions.

Statistics and monitoring

• Strategic direction: Enterprise monitoring
  • graphing and data aggregation tools, server monitoring, etc.
  • customer has reported that Merlin is inadequate, should we enter into this market?

• QA request: better EXPLAIN:
  • required in order to debug performance issues in queries without knowing the query or the data;
  • the customer will only provide EXPLAIN and SHOW output, we need to debug based on that;

• QA request: PERSISTENT TABLE STATISTICS
  • required to ensure repeatable query execution for InnoDB;
  • may allow various statistics to be reported by the server regardless of engine;

• U/C at Oracle: OPTIMIZER tracing spetrunia: report actual estimates, and all decisions of the optimizer, including why an index was *not* picked, etc.

• Developed by Serg for MariaDB 5.3: Phone Home todo: make a web page on mariadb.org showing the results from the data being collected; pstoev: do we need to allow people to run their own reporting servers;

• Present in MySQL 5.5: Performance Schema
  • what do we want to do with it, embrace it, extend it?
  • or it is better to have more SHOW commands and INFORMATION_SCHEMA tables?
  • are going to use Facebook's user stats/index stats patch or create a PERFORMANCE_SCHEMA-based solution?

• FB request: log all SQL errors
  • serg: possible via AUDIT plugin, must back-port audit infrastructure from MySQL 5.5

• FB request: more options for controlling the slow query log
  • sample one out of every N queries or transactions ; with N ~ 99
  • filter queries based on rows examined, I/O performed, total lock wait time;

• idea: collect statistics per query text, or normalized query text and report;

• FB request: EXPLAIN the *actual* plan on a *running* statement; no progress indicators and numbers are needed;

• request by community: progress bar for queries such as LOAD DATA and SELECT;
  • something like SHOW PROGRESS PROCESSLIST ; SHOW QUERY PROGRESS;
  • what numbers are to be reported? time to elapsed, time to completion, number of rows processed?
  • how to estimate the total runing time of the query;

• FB request: limit total temptable size on the server; Already available per-query, but per-server needed;

• FB patch: Admission Control
  • limit number of concurrently running queries per user;
  • if all user queries are blocked, allow a few more queries to join;

• Kurt: Integration with log watching tools
  • alter log formats to make them compatible with tools;
  • include logwatch mysql-specific config file in packages/distributions;

• FB request: Better monitoring for replication:
  • seconds_behind_master computation is incorrect, sometimes is zero
  • a counter for the total number of bytes read by I/O thread that does not rotate on log rotation;
  • "seconds behind real master" to report the actual time the slave I/O thread is behind;

• community request: prevent full scans from running at all above a certain table size;
  • is existing max-join-size variable sufficient or more granula control is needed?

• FB patch: report the time spent in individual phases of query processing

Optimizer

• Implement UNION ALL without usage of a temporary table
• Persistent data statistics
• Cost model cleanup (Don't assume things are B-trees)
  • Consistent cost interface trough handler methods
• Put cost related constants into variables
  • Automatic tuning of cost constants for specific setup (SSD / TAPE)
• Grace HASH join (Need sponsor)
• Sort merge join (Need sponsor)
• Make optimizer switch more user friendly

Federated

• Generic query pushdown
• Apply it to federated
• Timours old list of tasks

Performance:

• Better multi CPU performance above 16 cores (Intel)
• Thread pool
• More scalable query cache under higher concurrency
  • Allow stale data

• Predictive parser to replace yacc based ; 5 % speedup for simpler queries
• Faster WHERE (a,b) in ((1,2),(2,3)...huge list...)
• Faster VIEW (Not open frm & parse query for every access); Speed up simple view handling 2x

Aria

• Concurrent UPDATE & DELETE (Need sponsor)
• Segmented key cache for Aria
• MIN/MAX indexes
• Index withing key pages to speed up lookup on compressed key pages.
• Fast next not same

Refactoring

• do_select refactoring to remove if's and make each code group (like end_select) smaller (small speedup and cleaner code)

Memory tables

- VARCHAR and BLOB support (Need sponsor)

User friendly features

• Better/safer upgrade (?)
• Better option files

Other things

• Percona patches