opt: use anti-join for INSERT ON CONFLICT DO NOTHING conflict detection #58679
Conversation
|
This change is |
There was a problem hiding this comment.
Reviewed 10 of 10 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @andy-kimball, @mgartner, and @RaduBerinde)
pkg/sql/opt/norm/rules/groupby.opt, line 18 at r1 (raw file):
# Note: EliminateGroupByProject should be located above # EliminateJoinUnderGroupByLeft so that it can remove any interfering Projects. [EliminateGroupByProject, Normalize]
[nit] maybe update the comment to explain why UpsertDistinctOn is not included.
pkg/sql/opt/optbuilder/insert.go, line 767 at r1 (raw file):
fetchScope.expr, on, memo.EmptyJoinPrivate,
is there a reason you don't want to use memo.EmptyJoinPrivate?
mgartner
force-pushed
the
use-anti-join-for-insert-conflict-do-nothing
branch
from
89f0de4
to
796973c
Compare
There was a problem hiding this comment.
Reviewable status:
pkg/sql/opt/norm/rules/groupby.opt, line 18 at r1 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
[nit] maybe update the comment to explain why
UpsertDistinctOnis not included.
Done.
pkg/sql/opt/optbuilder/insert.go, line 767 at r1 (raw file):
Previously, rytaft (Rebecca Taft) wrote…
is there a reason you don't want to use
memo.EmptyJoinPrivate?
Nope, just copied from some other places. I added a new commit that converts all other &memo.JoinPrivate{}s to memo.EmptyJoinPrivate.
There was a problem hiding this comment.
Reviewed 2 of 2 files at r2, 2 of 2 files at r3.
Reviewable status:
|
TFTR! bors r=rytaft |
|
Merge conflict. |
The addition of lookup anti-joins enables the usage of anti-joins,
instead of left joins and filters, for detecting conflicts in an
`INSERT ... ON CONFLICT ... DO NOTHING` statement. This simplifies the
query plans for these statements.
As a result of this change two normalization rules had to be updated:
1. `EliminateGroupByProject` no longer matches `UpsertDistinctOn`
expressions because they no longer are built with a `Project` as
a child.
2. The `AreValuesDistinct` helper function for
`EliminateDistinctOnValues` now detects when the left child of an
AntiJoin has distinct values. This is required for eliminating
`UpsertDistinctOn` unnecessary operators now that their inputs are
AntiJoins.
Release note (performance improvement): INSERT ... ON CONFLICT ... DO
NOTHING statements now use anti-joins for detecting conflicts. This
simplifies the query plan for these statements, which may result in more
efficient execution.
Release note: None
mgartner
force-pushed
the
use-anti-join-for-insert-conflict-do-nothing
branch
from
796973c
to
05a9be1
Compare
|
bors r=rytaft |
|
Build succeeded: |
opt: use anti-join for INSERT ON CONFLICT DO NOTHING conflict detection
The addition of lookup anti-joins enables the usage of anti-joins,
instead of left joins and filters, for detecting conflicts in an
INSERT ... ON CONFLICT ... DO NOTHINGstatement. This simplifies thequery plans for these statements.
As a result of this change two normalization rules had to be updated:
EliminateGroupByProjectno longer matchesUpsertDistinctOnexpressions because they no longer are built with a
Projectasa child.
AreValuesDistincthelper function forEliminateDistinctOnValuesnow detects when the left child of anAntiJoin has distinct values. This is required for eliminating
UpsertDistinctOnunnecessary operators now that their inputs areAntiJoins.
Release note (performance improvement): INSERT ... ON CONFLICT ... DO
NOTHING statements now use anti-joins for detecting conflicts. This
simplifies the query plan for these statements, which may result in more
efficient execution.
opt: replace &memo.JoinPrivate{} with memo.EmptyJoinPrivate
Release note: None