You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This fixes a number of instabilities found in Cascades when planning
certain type of queries that end up generating a relatively large number
of variations that might end up storing actual duplicates in the
memoization structure (which is permissible).
Essentially, the following issues were detected and resolved in this PR:
1. **Fix instability in hash calculation**: Certain expressions had
their hash unstable, because it includes hashing an `enum` member, which
is [known to be
unstable](https://bugs.openjdk.org/browse/JDK-8050217?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel).
This issue made it very difficult to compare planner traces from
different runs, since a planner trace might include the hash codes of
some expressions, and the hash code could change across different JVMs,
causing the comparator to report false negatives.
2. **Set instantiation with deterministic traversal order**: Certain
instantiations of `Maps.newIdentityHashMap` and `Sets.newHashSet` are
replaced with `LinkedIdentityMap`, resp. `LinkedIdentitySet`.
3. **Fix instability detected in Guava `StandardMutableNetwork`**: We
use Guava [`Network`
](https://guava.dev/releases/20.0/api/docs/com/google/common/graph/Network.html)
for the planner memoization structure, internally, the network uses a
hash map to store the parallel edges between network vertices, this is
exactly why we were getting the alternatives in different order as
explained above. Due to the way the `Network` code is written, it is not
possible to pass the (type of the) map to the builder, therefore, I went
ahead and copied enough of the code to be able to modify the map
construction and make it stable, which effectively fixed the issue, but
ideally, Guava should make it possible to control how these maps are
created, making it easier to use and reason about the code.
This fixes#3191.
---------
Co-authored-by: Normen Seemann <[email protected]>
Copy file name to clipboardExpand all lines: fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/query/plan/cascades/CascadesRuleCall.java
+29-20Lines changed: 29 additions & 20 deletions
Original file line number
Diff line number
Diff line change
@@ -32,13 +32,15 @@
32
32
importcom.google.common.base.Preconditions;
33
33
importcom.google.common.base.Verify;
34
34
importcom.google.common.collect.ImmutableList;
35
+
importcom.google.common.collect.Iterables;
35
36
importcom.google.common.collect.Sets;
36
37
37
38
importjavax.annotation.Nonnull;
38
39
importjava.util.Arrays;
39
40
importjava.util.Collection;
40
41
importjava.util.Collections;
41
42
importjava.util.Deque;
43
+
importjava.util.Objects;
42
44
importjava.util.Optional;
43
45
importjava.util.Set;
44
46
importjava.util.function.Function;
@@ -241,8 +243,7 @@ public Reference memoizeExpression(@Nonnull final RelationalExpression expressio
Copy file name to clipboardExpand all lines: fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/query/plan/cascades/LinkedIdentityMap.java
+5Lines changed: 5 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,11 @@ public void replaceAll(final BiFunction<? super K, ? super V, ? extends V> funct
0 commit comments