morgo

13 ms·

61.
by morgo 9y ago
The 767 limit is with the default row format. In 5.7 the row format changes, and allows 3000+
62.
by morgo 9y ago
See my reply to parent on why the max must be calculated (no false positives on duplicate key in edge case). The default row format changes in 5.7, so key size is max is now much larger.
63.
by morgo 9y ago
The reason is not that the indexes became larger, its that mysql has to protect against all 4 byte characters, since the standard defines the n in varchar(n) as chars not bytes. This is obviously exceedingly rare, but if if it instead trunc
64.
by morgo 9y ago
It is not true for innodb (default). See my other comments in this thread.
65.
by morgo 9y ago
With innodb it is variable storage regardless of varchar or char when UTF8.
66.
by morgo 9y ago
Hi! I am the product manager for the mysql server. I can confirm that for innodb, this is not the case - storage is the variable length. You might be thinking about the memory storage engine (and temp tables).
67.
by morgo 9y ago
Product Manager for the MySQL Server here. The default configuration for MySQL is for a server with 512M RAM: https://dev.mysql.com/doc/refman/5.7/en/memory-use.html .. so some improvement should be exp
68.
by morgo 9y ago
I think plague might be a stronger word than I would use, since I think there is always pressure on new entrants to exaggerate problems with existing technology. For example: I have several customers with 200TB databases on a single server
69.
by morgo 9y ago
We've made the first step in 8.0, by moving the data dictionary to use a transactional backing store internally (no more FRM files). This means we can now do atomic DDL (i.e. drop 3 tables with all/none semantics). Extending it t
70.
by morgo 9y ago
I looked into this for defaults for 5.7 and 8.0. Our performance team feels like ON is still the better default, as it applies to more workloads than not. Improvements were also made in 5.7 to partition the hash.
71.
by morgo 9y ago
There is an option called [super_]read_only designed for this use-case: https://dev.mysql.com/doc/refman/5.7/en/server-system-variab...
72.
by morgo 9y ago
MariaDB diverged from MySQL 5.5 (2010). I'm quite proud of what we've managed to achieve since then: - MySQL 5.6 (2013) https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html - MySQL 5.7
73.
by morgo 9y ago
I'm not sure if that was a question, but I'll answer :-) * For UUID, we've added helper functions to store it in insert-friendly order: http://mysqlserverteam.com/mysql-8-0-uuid-support/ * For Datetime +
74.
by morgo 9y ago
Not something we are currently looking at, but possible in the future. I am not quite the right person to answer if the storage engine API can handle the use case for this. It is a slightly different problem, in that you need to push down
75.
by morgo 9y ago
I think this echo's Rene's point about moving the cache closer to the application as well. I have some hypothetical numbers illustrating the impact of network latency: http://www.tocker.ca/2013/11/18&#x2F
76.
by morgo 9y ago
There are a number of subquery performance improvements in MySQL 5.6 (including semi join and materialization). These are not dependent on query cache. 5.7 also added a new derived merge optimization (subquery in the from clause). No curr
77.
by morgo 9y ago
I want to start by saying that gripes/land mines don't help anyone. We try to balance fixing these issues, while keeping a good upgrade story. XKCD does a good job of explaining the problem in https://xkcd.com/11
78.
by morgo 9y ago
The "X" comes from it being a crossover/hybrid protocol between SQL and a CRUD API. It has a lot of modern protocol features, and uses protobufs, which makes it easy to add new driver support. The CRUD API has overlap with
79.
by morgo 9y ago
It's not easily possible to tell from these numbers. For example: - You can see a hit, but what was the cost of a miss? If it was a point lookup, it is very low cost. - Comparing hits to inserts, does not show the cost added to every
80.
by morgo 9y ago
I would maybe start off by saying feature parity was/is never the goal. The original goal of MySQL was to be the "Ikea of databases" (both come from Sweden). Having said that, I think expectations on what is the minimal func
81.
by morgo 9y ago
TokuDB uses a write-optimized data structure. A B+tree like InnoDB is more read optimized (although writes scale well while the key pars of the tree are in memory). There will always be use-cases for each.
82.
by morgo 9y ago
I also have a list of what was released in MySQL 5.7: http://www.thecompletelistoffeatures.com/ I'll work on a new version for 8.0 at some point. In the mean time: http://mysqlserverteam.com/the-mysql-8
83.
by morgo 9y ago
We compete in the sense that Aurora is a fork of MySQL 5.6 (2013). As a product manager, I do watch Aurora (along with SQL Server, Postgres, MongoDB, MariaDB etc). I'd rather answer questions about our products if you don't mind
84.
by morgo 9y ago
What are MySQL's strong points today? It's an interesting question, because some of the features that I'm most proud of MySQL having are the ones which might miss your radar: * Performance_schema means that any time MySQL is
85.
by morgo 9y ago
I don't think it's common per-se, but it leads into the next point as well. Because of MVCC, what you are supposed to see (while returning non-stale results) gets complicated.
86.
by morgo 9y ago
Product Manager for the MySQL Server here (and post author). Happy to answer any questions...
87.
by morgo 9y ago
Correct. See my post here: http://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-ove...
88.
by morgo 9y ago
Indeed, latin1 is currently the default for MySQL. But it changes to utf8 in MySQL 8.0 (in development).
89.
by morgo 9y ago
For this use case, yes. ProxySQL also natively supports Group Replication though so you are free to chose either.
90.
by morgo 9y ago
Certification of transactions is done on transaction commit. If two people have modified the same data, then one of them will get a similar error to a deadlock. The other is free to proceed.

More ›