Are there any plans in the roadmap to add simple analytical / window function support etc. to mysql?
I suspect that perhaps these features (and others like Common Table Expressions, bitmap indexing etc). require too much of the core code to be revised etc? Could you shed a little light on that?
Yes there are plans to add window functions (no timeframe yet).
MySQL 8.0 will support CTEs (both WITH and WITH RECURSIVE). Bitmap indexes: work best with HEAP tables. InnoDB is a clustered index, so adding them may be a little harder.
With the shift to utf8mb4, are indexes / keys still stored as the maximum possible length (ie length *4 bytes)? and is the maximum key length still ~750 bytes?
I asked some of my developers to look into converting to utf8mb4 from utf8 in one of our legacy codebases, but we hit a problem with indexed fields that were defined as varchar(255).
One of the challenges we have with adding new data types in general is actually figuring out all of the implicit type conversions for non-STRICT mode. While MySQL now defaults to strict (5.7+), we have to continue to be able to support users upgrading from earlier versions.
Congratulations for this release. I've struggled with time series in MySQL. Is support for in-memory time series I could join with in the roadmap? Thanks!
We have table partitioning, which works very well for time series data.
But yes, one performance characteristic of clustered indexes like InnoDB is they tend to be slower for append workloads. We have some optimizations to mitigate this (change buffering), but this is a use case we care about and are looking into improving.
21 comments
[ 4.2 ms ] story [ 53.3 ms ] threadAre there any plans in the roadmap to add simple analytical / window function support etc. to mysql?
I suspect that perhaps these features (and others like Common Table Expressions, bitmap indexing etc). require too much of the core code to be revised etc? Could you shed a little light on that?
MySQL 8.0 will support CTEs (both WITH and WITH RECURSIVE). Bitmap indexes: work best with HEAP tables. InnoDB is a clustered index, so adding them may be a little harder.
I asked some of my developers to look into converting to utf8mb4 from utf8 in one of our legacy codebases, but we hit a problem with indexed fields that were defined as varchar(255).
You can actually make 5.5+ support larger key lengths, but it requires:
* Table created with ROW_FORMAT=DYNAMIC
* innodb_file_per_table ON
* innodb_large_prefix ON
* innodb_file_format set to Barracuda
Yes it's a pain. We've been working a lot harder on defaults since 5.6+ Here's a list of what we are looking at changing in 8.0:
http://mysqlserverteam.com/planning-the-defaults-for-mysql-5...
http://mysqlhighavailability.com/mysql-replication-defaults-...
One of the challenges we have with adding new data types in general is actually figuring out all of the implicit type conversions for non-STRICT mode. While MySQL now defaults to strict (5.7+), we have to continue to be able to support users upgrading from earlier versions.
But yes, one performance characteristic of clustered indexes like InnoDB is they tend to be slower for append workloads. We have some optimizations to mitigate this (change buffering), but this is a use case we care about and are looking into improving.