The following is a list of features considered for 5.6.
As soon as 5.3/5.5 is declared gamma we have to decode who will work on what features for 5.6. All features that has a designed developer who agrees to get the thing done in a given timeline will be considered as a 5.6 feature. Then we will also create a new kb page with the to-be-done features.
The items below that have a name after them are already allocated to a developer.
- 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.
- optimize simple queries with Intersects(), Within, Distance()<X
- add Distance_sphere() and the related optimization.
- 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 (Done by Monty: Syntax added in 5.3; When ONLINE is used, one gets an error if the ALTER TABLE can't be done online)
- 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
- 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 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)
- Binlog events checksums MWL#180 (DONE in 5.3)
- Multi source (Slave can have multiple masters). MWL#201. There is a partial sponsorship for this already.
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 (In Progress)
- request by community: progress bar for queries such as LOAD DATA and
- 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
- 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)
- 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.
- Generic query pushdown
- Apply it to federated
- Timours old list of tasks
- 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
- Concurrent UPDATE & DELETE. MWL#235 (Have partial 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
- do_select refactoring to remove if's and make each code group (like end_select) smaller (small speedup and cleaner code)
- VARCHAR and BLOB support (Have sponsor; Will be implemented for 5.5)
User friendly features
- Better/safer upgrade (?)
- Better option files in distributions.
- Table functions (Timour)
- UNIQUE CONSTRAINT for BLOB (WL#139)
- Percona patches (Monty & Sanja)
- LGPL/BSD client library (MP)
- Enhance RQG to test for query correctness and performance on production workloads during upgrade (MWL#178)