MySQL 5.8 Planning: C++11 and Native Partitioning

In November we held our first MySQL 5.8 planning session in London. On behalf of the MySQL team, I would like to thank you for your feature requests and suggestions. We reviewed over 150 pieces of feedback in total, and are looking forward to prioritizing a number of suggestions:

In MySQL 5.8, we are planning to make two important changes to modernize our code base. To explain each in more detail:

C++11 Required

We are looking forward to being able to use the new atomics support in C++11 in new feature development, as well as cleaning up and simplifying existing code as time allows.

Since this change requires compiler support, our minimum requirements will also increase. For Linux the minimum will now be EL6, and Windows will now require Visual Studio 2015.

Native Partitioning Required

In MySQL 5.7 we moved partitioning from being a Storage Engine that sits above other Storage Engines to being part of the Storage Engine API itself. We describe this difference as “native partitioning”; the advantage is that we are able to improve memory usage, and more easily implement new features such as foreign key support and global indexes.

We are happy with the feedback we have received so far on native partitioning (from a user upgrading perspective, it is only a meta-data change). In MySQL 5.8, we are planning to remove support for non-native partitioning. This change will bring some simplification to development as storage engines will now own tables and indexes.

Please get in touch

If either of these changes affect you, please get in touch. We would be happy to work with you and help with upgrading.

Thank you for using MySQL!

9 thoughts on “MySQL 5.8 Planning: C++11 and Native Partitioning

  1. Thanks for sharing! In the meantime, maybe you guys can update the Windows MySQL Installer and replace the URL for testing Internet connectivity with either some Oracle/MySQL owned/controlled URL or simply or — or just doing a DNS lookup for The problem with is that requesting that URL may result in a redirect to Google’s ccTLD domains. Of course, if and/or their ccTLDs are blocked, this check will fail.

    By the way, using as URL for checking Internet connectivity is a joke, right?

  2. public bool HasInternetConnectivity()
    IPHostEntry ipHostEntry = Dns.GetHostEntry(“”);
    return true;
    return false;

    The above should do the trick.

  3. While official support for POWER is something I wish for in the 5.7 timeframe rather than having to wait until 5.8, I’d have it on my wishlist anyway.

    C++11 seems like a pretty sensible option, and EL6 is pretty ancient anyway, especially for targetting 5.8 to – you could probably even go more recent for minimal GCC versions.

    The biggest thing on my wishlist? More transparent and participatory development. While being able to submit patches to bugs or file pull requests on github is *okay*, having no visible development tree severely impacts what kind of patches can be sent upstream, as well as the delay in having things merged does make you wonder if spending more effort on upstreaming is a productive use of valuable engineering time.

    Also, since so many discussions are in secret, you may not find out about a choice until months (years?) later… and diffing labs releases to find out what possible patches may go in isn’t exactly a user friendly process.

    I’d love to see a focus on single threaded performance, something which has steadily declined over releases.

Leave a Reply