4 ms·

Product Manager for the MySQL Server here. Happy to answer questions!

by morgo 10y ago

dfsegoat 10y ago
Hi. Thanks for taking the time. 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?
- morgo 10y ago
  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.
  - dfsegoat 10y ago
    Great to know, thanks!
hdjjhhvvhga 10y ago
Does this release have the recent SQL code execution bug patched?
- morgo 10y ago
  No.
jlawer 10y ago
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).
- morgo 10y ago
  This was fixed by a defaults change in MySQL 5.7. 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-8/ http://mysqlserverteam.com/planning-the-defaults-for-mysql-5... http://mysqlhighavailability.com/mysql-replication-defaults-after-5-7/ http://mysqlhighavailability.com/mysql-replication-defaults-...
- deleted 10y ago
  [deleted]
needusername 10y ago
Any plans for TIMESTAMP WITH TIME ZONE?
- morgo 10y ago
  No immediate plans, but it has come up before. 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.
kiliancs 10y ago
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!
- morgo 10y ago
  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.

Product Manager for the MySQL Server here. Happy to answer questions!

by morgo 10y ago

Product Manager for the MySQL Server here. Happy to answer questions!

Hi. Thanks for taking the time. 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?

morgo 10y ago
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.
- dfsegoat 10y ago
  Great to know, thanks!

hdjjhhvvhga 10y ago

Does this release have the recent SQL code execution bug patched?

morgo 10y ago
No.

jlawer 10y ago

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).

morgo 10y ago
This was fixed by a defaults change in MySQL 5.7. 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-8/ http://mysqlserverteam.com/planning-the-defaults-for-mysql-5... http://mysqlhighavailability.com/mysql-replication-defaults-after-5-7/ http://mysqlhighavailability.com/mysql-replication-defaults-...
deleted 10y ago
[deleted]

needusername 10y ago

Any plans for TIMESTAMP WITH TIME ZONE?

morgo 10y ago
No immediate plans, but it has come up before. 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.

kiliancs 10y ago

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!

morgo 10y ago
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.