Add planner configuration property to control union ordering key behavior #2408
Assignees
Labels
bug
Something isn't working
Comments
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Dec 13, 2023
…l union ordering key behavior In order to avoid breaking continuations of plans affected by FoundationDB#2336, this adds a planner configuration flag that allows the user to effectively revert to the old behavior. This property is set to the old behavior by default, letting users to opt-in to the new behavior if they know it is safe for their deployment. This also includes a bit of a revamp of the or query tests to make sure all of the configurations get tested. There were two queries that had their plan hashes updated in FoundationDB#2350 (resolving FoundationDB#2336). The plan hashes in this PR for the legacy mode match the old plan hashes from before FoundationDB#2350 went in. This fixes FoundationDB#2408.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Dec 13, 2023
…l union ordering key behavior In order to avoid breaking continuations of plans affected by FoundationDB#2336, this adds a planner configuration flag that allows the user to effectively revert to the old behavior. This property is set to the old behavior by default, letting users to opt-in to the new behavior if they know it is safe for their deployment. This also includes a bit of a revamp of the or query tests to make sure all of the configurations get tested. There were two queries that had their plan hashes updated in FoundationDB#2350 (resolving FoundationDB#2336). The plan hashes in this PR for the legacy mode match the old plan hashes from before FoundationDB#2350 went in. This fixes FoundationDB#2408.
MMcM
pushed a commit
that referenced
this issue
Dec 13, 2023
…ring key behavior (#2409) In order to avoid breaking continuations of plans affected by #2336, this adds a planner configuration flag that allows the user to effectively revert to the old behavior. This property is set to the old behavior by default, letting users to opt-in to the new behavior if they know it is safe for their deployment. This also includes a bit of a revamp of the or query tests to make sure all of the configurations get tested. There were two queries that had their plan hashes updated in #2350 (resolving #2336). The plan hashes in this PR for the legacy mode match the old plan hashes from before #2350 went in. This fixes #2408.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Feb 7, 2024
… order for In union This takes basically the same approach that was taken for FoundationDB#2350, but this time applying it to `InUnion` plans rather than just regular union plans. This change is guarded behind a planner configuration plan. This is necessary because the new algorithm can choose new ordering keys for the in-union, and so the user needs to be able to control its roll out. This is to mirror what we did with FoundationDB#2408. This resolves FoundationDB#2493.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Feb 7, 2024
… order for In union This takes basically the same approach that was taken for FoundationDB#2350, but this time applying it to `InUnion` plans rather than just regular union plans. This change is guarded behind a planner configuration plan. This is necessary because the new algorithm can choose new ordering keys for the in-union, and so the user needs to be able to control its roll out. This is to mirror what we did with FoundationDB#2408. This resolves FoundationDB#2493.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Feb 7, 2024
… order for In union This takes basically the same approach that was taken for FoundationDB#2350, but this time applying it to `InUnion` plans rather than just regular union plans. This change is guarded behind a planner configuration plan. This is necessary because the new algorithm can choose new ordering keys for the in-union, and so the user needs to be able to control its roll out. This is to mirror what we did with FoundationDB#2408. This resolves FoundationDB#2493.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Feb 7, 2024
… order for In union This takes basically the same approach that was taken for FoundationDB#2350, but this time applying it to `InUnion` plans rather than just regular union plans. This change is guarded behind a planner configuration plan. This is necessary because the new algorithm can choose new ordering keys for the in-union, and so the user needs to be able to control its roll out. This is to mirror what we did with FoundationDB#2408. This resolves FoundationDB#2493.
alecgrieser
added a commit
that referenced
this issue
Feb 23, 2024
…n union (#2496) This takes basically the same approach that was taken for #2350, but this time applying it to `InUnion` plans rather than just regular union plans. This change is guarded behind a planner configuration plan. This is necessary because the new algorithm can choose new ordering keys for the in-union, and so the user needs to be able to control its roll out. This is to mirror what we did with #2408. This resolves #2493.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With #2336 (fixed by #2350), the comparison keys on ordered union plans can change. This can result in plans changing, potentially in ways that can invalidate the continuation. We should have a planner configuration property that allows users to opt in to the old behavior, even though (I think) the old plans should always be worse. This property can allow the user to control when they decide to roll this feature out.
The text was updated successfully, but these errors were encountered: