Repository navigation
Multiple calls to the same volatile function do not produce different answers #8518
Copy link
Copy link
Closed
Labels
bugSomething isn't workingSomething isn't working
Description
Describe the bug
When I call a function like random() twice I expect to get different values, but I only get a single value
To Reproduce
❯ select random() r1, random() r2;
+--------------------+--------------------+
| r1 | r2 |
+--------------------+--------------------+
| 0.5798857099939392 | 0.5798857099939392 |
+--------------------+--------------------+
1 row in set. Query took 0.002 seconds.Expected behavior
I expect the values from the two different calls to random() to be different
Additional context
The explain plan shows what is wrong:
❯ explain select random() r1, random() r2;
+---------------+--------------------------------------------------------------------+
| plan_type | plan |
+---------------+--------------------------------------------------------------------+
| logical_plan | Projection: random() AS random() AS r1, random() AS random() AS r2 |
| | Projection: random() AS random() |
| | EmptyRelation |
| physical_plan | ProjectionExec: expr=[random()@0 as r1, random()@0 as r2] |
| | ProjectionExec: expr=[random()] |
| | PlaceholderRowExec |
| | |
+---------------+--------------------------------------------------------------------+And explain verbose shows the problem is introduced in logical_plan after common_sub_expression_eliminate:
❯ explain verbose select random() r1, random() r2;
+------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
| plan_type | plan |
+------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
| initial_logical_plan | Projection: random() AS r1, random() AS r2 |
| | EmptyRelation |
| logical_plan after inline_table_scan | SAME TEXT AS ABOVE |
....
|
| logical_plan after eliminate_cross_join | SAME TEXT AS ABOVE |
| logical_plan after common_sub_expression_eliminate | Projection: random() AS random() AS r1, random() AS random() AS r2 |
| | Projection: random() AS random() |
| | EmptyRelationReactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Activity
alamb commentedon Dec 12, 2023
Interestingly 2a69244 gets the right answers;
$ git checkout 2a692446f46ef96f48eb9ba19231e9576be9ff5a $ cd datafusion-cli $ cargo run ...It looks like
push_down_projectionundoes the optimization somehowDetails
alamb commentedon Dec 12, 2023
This appears to have been exposed in #8340 from @jonahgao and @haohuaijin (the bug has existed for quite a while, but previously it got "undone" by projection pushdown):
For some reason I don't understand, something about #8340 seems to expose us to this bug downstream in IOx
viirya commentedon Dec 12, 2023
The correctness relying on the order of optimization rules is somehow flaky and easily to be broken. I think we should disallow volatile expressions to be targets of common subexpr elimination at the beginning: #8520
alamb commentedon Dec 12, 2023
I agree -- thank you @viirya -- I will review that PR shortly