tag:blogger.com,1999:blog-9149523927864751087.post9139284823534675408..comments2024-03-26T09:43:01.052-07:00Comments on Small Datum: Low-concurrency performance for range queries: MySQL 5.7 vs previous releasesMark Callaghanhttp://www.blogger.com/profile/09590445221922043181noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-9149523927864751087.post-74445979781737284722014-10-04T11:21:10.308-07:002014-10-04T11:21:10.308-07:00Thank you for your continued work in benchmarking ...Thank you for your continued work in benchmarking MySQL.<br /><br />I see that for Scan 1000, non-covering secondary, 1 thread, performance is indeed 2.67X the baseline. But 5.0.85 is around 2.44X, so 5.7 is not that bad, right?<br /><br />The problem is non-trivial, and I think you are absolutely right that there is not one push, or not even a few pushes, that are to blame for the regression.<br /><br />Our strategy in the optimizer group is to streamline the query processing, clean up interfaces, avoid double work, and avoid work that has to be rollbacked later. The main purpose of this work is to make the optimizer easier to maintain and extend, but there is also an important secondary goal of making the processing more efficient. I hope that we will see effects from that work soon, although when we add new features into the optimizer, it is challenging to retain old efficiency.<br /><br />For the 1X tests, most regression is probably in the optimizer domain (which in this respect includes the parser, resolver, optimizer and executor), but for 1000X tests, the blame can probably be shared with InnoDB. But we need to run some perf tests to tell for sure...Roy Lysengnoreply@blogger.com