Features in 10.0 releases are listed on the What is MariaDB 10.0? page.
- MariaDB 10.0 Definite
- MariaDB 10.0 partly sponsored features
- MariaDB 10.0 High Probability
- MariaDB 10.0 Rolling
- Will skip for 10.0
The following is a list of features considered for 10.0 and 10.x
All features that has a designed developer who agrees to get the thing done in a given timeline will be considered as a 10.0 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.
We will port to MariaDB 10.0 and rewrite many (but not all) of the features from MySQL 5.6. 10.1 will have more of the 5.6 features and 10.2 should have the rest. The reason for this is to be able to release MariaDB 10.0 without having to wait until all MySQL 5.6 features are stable or rewritten.
Note that a lot of the main features in MySQL 5.6 are already present (and in optimized form) in MariaDB 5.5.
For a full list of what's already back ported/rewritten from MySQL 5.6 and what's left to do, look at the TODO file in the top directory of the MariaDB source tree. If you want to be part of developing MariaDB, this is a good place to start!
MariaDB 10.0 Definite
MariaDB 10.0 partly sponsored features
Features that are likely to be in 10.0 if we can get more sponsorships
- FB request: Better monitoring for replication (FB has patch; MP will add) (kristian) (for 5.5 or 10.0)
- Aria: Concurrent UPDATE & DELETE. MWL#235 (Have partial sponsor) (monty) - MDEV-23
- Aria: Segmented key cache for Aria (By Igor for 10.0 or 10.1) - MDEV-24
- Aria: Fast next-not-same handler call (monty) (Target 10.0) - MDEV-25
- From MySQL 5.6: Global transaction ID, so the slave state becomes recoverable, and facilitate automatic moving a slave to a new master across multi-level hierarchies. - MDEV-26
MariaDB 10.0 High Probability
Features which have a high probability of being in MariaDB 5.6
- Performance: More scalable query cache under higher concurrency (Sanja) (maybe) - MDEV-4454
- Allow stale data (Sanja) (maybe)
MariaDB 10.0 Rolling
Features which will be added when they are ready.
- Parameterized Views
- Percona patches (Monty & Sanja) (rolling feature)
Will skip for 10.0
Features which are not likely to be ready for MariaDB 10.0
- Community Request: prevent full scans from running at all above a certain table size;
- is existing
max-join-sizevariable sufficient or more granula control is needed?
- is existing
- Optimizer: Implement UNION ALL without usage of a temporary table (nice to have) (wait for sponsor)
- Federated: Generic query pushdown
- Federated: Apply it to federated
- Federated: Timour's old list of tasks (Timour)
- Table functions (Timour) (after 5.6)
- Refactoring: do_select refactoring to remove if's and make each code group (like end_select) smaller (small speedup and cleaner code)
Features which have not been categorized into the above categories.
- OpenGIS: prefill the spatial_ref_sys table. (Holyfoot) - MDEV-60
- OpenGIS: Add possible III-rd coordinate (Altitude). (Holyfoot)
- OpenGIS: Distance3D, related optimization.
- OpenGIS: 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
- Extended timestamp > 2038
- 1M tables Information schema (MP will investigate)
- 1M users requirements
- Roles - MDEV-4397
- 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
- Transactional storage of slave state, rather than file-based master.info and relay-log.info . So the slave can recover consistently after a crash.
- 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)
- Multi source (Slave can have multiple masters). MWL#201. There is a partial sponsorship for this already. (Monty and Kristian) - MDEV-253
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, MariaDB Corporation, 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; (need examples)
- Perhaps optimizer trace is what we need
- QA request: engine independent PERSISTENT TABLE STATISTICS (Igor) - MDEV-204
- required to ensure repeatable query execution for InnoDB;
- may allow various statistics to be reported by the server regardless of engine;
- able to simulate different sized tables
- U/C at Oracle: OPTIMIZER tracing
spetrunia: report actual estimates, and all decisions of the optimizer,
including why an index was *not* picked, etc.
- want to change for 5.7
- FB request: more options for controlling the slow query log MWL#181 (Holyfoot will check)
- 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;
- request by community: progress bar for SELECT;
- how to estimate the total running time of the query;
- Percona has support for this
- 5.3 has progress reporting for SHOW PROGRESS PROCESSLIST; SHOW QUERY PROGRESS; and LOAD DATA .
- FB request: limit total temptable size on the server (MP) MWL#183
- FB patch: Admission Control (MP) (seriously considered to be done) (wlad)
- limit number of concurrently running queries per user;
- if all user queries are blocked, allow a few more queries to join;
- Integration with log watching tools
- alter log formats to make them compatible with tools;
- include logwatch mysql-specific config file in packages/distributions;
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)
- FB patch: report the time spent in individual phases of query processing (MP)
- Put cost related constants into variables (will be done) (timour)
- Automatic tuning of cost constants for specific setup (SSD / TAPE)
- Make optimizer switch more user friendly (Sanja and Spetrunia) (will be done)
- Cost model cleanup (Don't assume things are B-trees) (timour)
- Consistent cost interface trough handler methods
- Persistent data statistics (Igor)
- Grace HASH join (Need sponsor)
- Sort merge join (Need sponsor)
- Better item_equal (Igor & Monty)
- missing item_equal for ORDER BY and GROUP BY
- Less fetches of data pages.
- can use whenever you have many-to-many relationships between two tables
- use to try to minimize data access
- it's like INDEX INTERSECTION
- Performance: Better multi CPU performance above 16 cores (Work with Intel)
- Performance: Predictive parser to replace yacc based ; 5 % speedup for simpler queries
- Performance: Faster WHERE (a,b) in ((1,2),(2,3)...huge list...) (customer request)
- Performance: Faster VIEW (Not open frm & parse query for every access); Speed up simple view handling 2x
- MIN/MAX indexes
- Index withing key pages to speed up lookup on compressed key pages.
User friendly features
- Better/safer upgrade (?)
- Better option files in distributions.
- UNIQUE CONSTRAINT for BLOB (MWL#139) (medium)
- Enhance RQG to test for query correctness and performance on production workloads during upgrade (MWL#178) (prototype done, need to get outside users to verify the code)
- 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)
Plugins by Sergei
- Plugins by Sergei: query rewrite (MWL#144)
- Plugins by Sergei: full-text search engine plugin (MWL#143)
- Plugins by Sergei: Plugin Loader (MWL#162)
- Plugins by Sergei: smaller, nice to have, tasks: