[MDEV-21285] RAND()/ENCODE() lack of concurrency Created: 2019-12-11 Updated: 2021-03-08 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Server |
| Affects Version/s: | 10.4.11 |
| Fix Version/s: | 10.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Daniel Black | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Inital report from otto on zulip |
| Comments |
| Comment by Marko Mäkelä [ 2019-12-12 ] | |
|
It looks like a significant amount of time is being spent in a floating-point instruction. But, can we avoid it in this particular case, without breaking compatibility? The test case rand-test.lua
As far as I understand the code of the ENCODE function in Item_func_encode::val_str(), both arguments are internally converted to strings. So, apparently, for compatibility, the RAND() value must be a floating-point value between 0 and slightly less than 1 that is then converted to a string. I do not see an easy way to replace the floating-point arithmetics with integer arithmetics. As far as I can tell, we could theoretically ‘push down’ things like integer_constant*RAND() to a new predefined function INT_RAND(integer_constant) and then override Item::val_int() for it. Perhaps we could similarly translate ENCODE(something, RAND()) into ENCODE(something, INT_RAND(1<<32)), but I would say that it is approaching a gray area when it comes to the resulting distribution of the data. | |
| Comment by Daniel Black [ 2019-12-16 ] | |
|
Yeh, was coming to the same conclusion. That `RAND()`, `UUID()` all to some extent need the same questionable RND algorithms as the randoms seeds end up in the binary log and that `binlog_format=statement` is still a thing. sql/password.c might be fixable. Moving existing implementation to `my_not_rnd` and adding a proper implementation like the `my_rnd_ssl`, except actually used (and integer based). |