morgo

17 ms·

121.
by morgo 10y ago
This limitation had to be lifted for CTEs to be reused, which is in the same labs release as the JSON functions mentioned here. I haven't checked yet if it is lifted for CTEs only, or all cases. But CTEs are a replacement for most (al
122.
by morgo 10y ago
Yes. We wanted to be able to drop the leading 5. For context: 6.0 was a canceled release. 7.x. is used by Cluster. 8.0 makes it easy to follow as "it just drops the 5".
123.
by morgo 10y ago
The mapping is not strictly one index per field, but a virtual column expression must map to a MySQL type. So depending on the use-case you may be able to use more complicated expressions to limit indexes. But to expand your question, ther
124.
by morgo 10y ago
It sounds like a JSON_TABLE function: https://docs.oracle.com/database/121/SQLRF/functions092.htm#... We are looking to add something similar.
125.
by morgo 10y ago
Just to clarify: s/architecture/implementation/ InnoDB is MVCC too, but does an update in place with relocation of the old row to UNDO space. There are pros and cons to both approaches.
126.
by morgo 10y ago
The engineering team is 2x the size that it was at the time of the Oracle acquisition. 8.0 is the release where some of the investments are starting to pay off :) Invisible indexes was one of my FRs, so very happy to hear you like it. For
127.
by morgo 10y ago
Here is an example: http://mysqlserverteam.com/indexing-json-documents-via-virtu... The optimizer will match JSON expressions to virtual columns w/indexes. So that means you can keep your queries in this form and have
128.
by morgo 10y ago
MySQL Product Manager here. For a more general overview of 8.0, see: http://mysqlserverteam.com/the-mysql-8-0-0-milestone-release... This feature is part of the optimizer labs release, which also includes CTEs: http:/
129.
by morgo 10y ago
No partial update yet, but we are working towards it - The json binary format spec allows for padding. Search in page for 'BLOB' for details: http://mysqlserverteam.com/the-mysql-8-0-0-milestone-release...
130.
by morgo 10y ago
In InnoDB everything is a transaction. If you do not begin/commit then each statement will be its own transaction. Batching a group of statements together in a small transaction is usually better because it reduces log flushing. ACID
131.
by morgo 10y ago
MySQL Product Manager here. Any feedback on the Storage Engine API?
132.
by morgo 10y ago
Good article. I've stopped using bank transfers as an example for Acid transactions, and instead talk about social features: - if I change a privacy setting in Facebook or remove access to a user, these changes should be atomic and dur
133.
by morgo 10y ago
I'm not sure what it is, but it seems everyone struggles with 6.0. Perl made it, but it took a while :)
134.
by 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
135.
by 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 (c
136.
by 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 t
137.
by morgo 10y ago
6.0 was a canceled release. 7.x. is used by Cluster. 8.0 makes it easy to follow as "it just drops the 5".
138.
by morgo 10y ago
No.
139.
by 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.
140.
by morgo 10y ago
Product Manager for the MySQL Server here. Happy to answer questions!
141.
by morgo 10y ago
Logging and storage being new does not mean it does not share a lot of other internals.
142.
by morgo 10y ago
Sure it does. You can see this from diagnostic commands (Innodb status, mutexes etc)
143.
by morgo 10y ago
For context: Faster indexing and numa awareness is in MySQL 5.7. The parallel read-ahead is a Facebook patch. Aurora is based on MySQL 5.6.
144.
by morgo 10y ago
You are comparing apples to oranges here. MySQL had a different (and more successful) business model. No MariaDB did not get all the core devs.
145.
by morgo 10y ago
You can do something like this for doing a cross version approach: SELECT /*!50706 authentication_string as */ password FROM mysql.user; I wrote about the rationale to some of the password changes here: http://ww
146.
by morgo 10y ago
Prioritization is based on a few things (customer demand, trends in the market in general). Besides prioritization, there is a resourcing component too (the server is split into several teams with specific expertise). In general I would sa
147.
by morgo 10y ago
They started diverging at MySQL 5.5.
148.
by morgo 10y ago
6.0 was a canceled release. 7.x. is used by Cluster. 8.0 is the next number along, and makes it easy to follow as "it just drops the 5".
149.
by morgo 10y ago
I would say this is not just a case of faster, but more aware. Linux does not have the same meta-data knowledge that the native cache has. There is a layering problem which makes it hard to add this. For example: after some page splits an
150.
by morgo 10y ago
I bought the domain name. It's not a minor release. MySQL predates semver. It is not alone here (see Mac OS X; PostgreSQL etc.). But you will be happy to hear that the next version will be called 8.0.

More ›