Plans for 5.6

OpenGIS compliance

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

• Add possible III-rd coordinate (Altitude). (Holyfoot)
• 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)
• Online extension of any NUMERIC datatype ; Like ALTER tinyint -> smallint
• Extend ENUM done need more visibility
• Alter comment (Monty)
• Online Add and drop index (Drop is easy to implement MyISAM/ARIA)
• Online OPTIMIZE
• Online ANALYSE
• Add ALTER ONLINE TABLE (Monty)
• Look at patch for online backport sent to maria-developers

COMPATIBILITY & USABILITY

• Date & time embedded timezone (Need sponsor)
• IPV6 native type
  • Functions ; Functions exists in public patch (MP)
  • Datatype ;Old patch exists
• Extended timestamp > 2038
• 1M tables Information schema (MP will investigate)
• 1M users requirements
  • Roles
• mysql.* in any engine
• LOG tables in a log_schema schema
• User Ldap Authentification like Drizzle
• Make openssl hash functions available for user. (Bank will sponsor)
• Query logging and summary per query MWL#179
• Auditing for specific user (to general log)
• 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.
• Reduce fsyncs from 3 to 1 in group commit with binary log (MWL#164)
• Parallel applying of binary log in slave (MWL#169)
• Replication APIs, as per MWL#107 (Needs sponsor)
  • Most important MWL#120 and MWL#133, for obtaining and applying events.
  • Then a mechanism for prioritizing transactions.
• Binlog events checksums MWL#180

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? (MonYog, SkySQL, Percona, Oli Sennhauser, Open Query etc is doing tools)

• QA request: better EXPLAIN (HIGH priority; MP; Spetrunia)
  • 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 (Igor)
  • 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 (Holyfoot or Bryan); 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? (MP + Percona)

• FB request: log all SQL errors (Holyfoot to do in 5.5); MWL#177

• FB request: more options for controlling the slow query log MWL#181
  • sample one out of every N queries or transactions ; with N ~ 99 (Patch by FB; Will be changed to use AUDIT)
• 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; MWL#182

• 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 running time of the query;
  • Percona has support for this .
• FB request: limit total temptable size on the server (MP) MWL#183

• FB patch: Admission Control (MP)
  • 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 (FB has patch; MP will add)
  • 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 (MP will look into this)

• 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 (MP)

Optimizer

• Implement UNION ALL without usage of a temporary table
• Persistent data statistics (Igor)
• 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 (Sanja)
• Better item_equal (Igor & Monty)
• Less fetches of data pages.

Federated

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

Performance:

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

• 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 in distributions.
• Table functions (Timour)
• UNIQUE CONSTRAINT for BLOB (WL#139)

Other things

• Percona patches (Monty & Sanja)
• LGPL/BSD client library (MP)

Plugins

• query rewrite (WL#144)
• full-text search engine plugin (WL#143)
• Plugin Loader (WL#162)
• smaller, nice to have, tasks:
  • show plugins soname ... (WL#80)
  • mutex/condition service (WL#83)
  • INSTALL PLUGIN * (WL#77)
  • duplicate plugin names (WL#79)
  • create a charset service (WL#81)