| 773 | |
| 774 | == Optimization and precision maths == |
| 775 | |
| 776 | A very interesting read is https://dev.mysql.com/doc/refman/5.7/en/precision-math.html (and its sub-sections: Click on ''Next''). |
| 777 | |
| 778 | In short: A value like 1.234 is an ''exact'' value and exact math calculation are performed. If a value is given as an approximate ''floating-point'' value (which all '''DOUBLE''' columns are), for example 1.234e0, the calculation is ''not exact''. ''Not exact'' means that it using (faster) ''floating-point'' arithmetic rather than (slower) ''exact'' arithmetic. |
| 779 | |
| 780 | Now, any mathematical operation which at least contains one ''floating-point'' number is evaluated as a floating-point approximation. This sounds very simple and as if it has nothing to do with our analysis, but it has: |
| 781 | |
| 782 | All the numbers in the previous SQL queries were given as ''exact'' numbers and thus stored by the engine as ''exact'' numbers. Whenever they take place in one of our calculations, they have to be converted to a floating-point value first (it seems this does not happen in advance but during run-time), which is an operation which is obviously not for free. |
| 783 | |
| 784 | So as a test, let's append a `e0` to all fractional values in the query, e.g. instead of `0.5`, let's write `0.5e0` (or `5e-1`). This essentially tells the SQL engine to store the value as an approximate ''floating-point'' value and not as an ''exact'' value. Now, let's run the query again... |
| 785 | |
| 786 | And voila! |
| 787 | |
| 788 | {{{ |
| 789 | Execution time: 10.1325s |
| 790 | }}} |
| 791 | |
| 792 | ''This is again much faster!'' |
| 793 | |
| 794 | {{{#!div style="background: #8d8; border: 3px ridge" |
| 795 | Conclusion: Wherever you use floating-point values in your query and you are not interested in a 100% machine independent result, write them as ''floating-point'' values by appending `e0` instead of ''exact'' values. |
| 796 | }}} |