Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: implement differential testing of physical plans produced by the old and new factories #50610

Open
yuzefovich opened this issue Jun 24, 2020 · 2 comments
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-queries SQL Queries Team
Projects

Comments

@yuzefovich
Copy link
Member

yuzefovich commented Jun 24, 2020

With the work being tracked by #47473 we're introducing a new exec.Factory implementation that creates processor specs directly and constructs the physical plan without the need to have an intermediate planNode tree. Eventually new factory will replace the old one. However, to get there we need to be certain that we don't introduce any changes to the physical plans (apart from the ones that are deliberate, e.g. having partially distributed plans).

One approach that we could take for that is to use differential testing of the physical plans produced by the new factory on one side and the old factory + distsql physical planner on the other. The goal is to make sure that the plans are "equal deeply", and we probably can reuse some serialized representation of the whole plan for that (likely existing marshaling methods of the specs - which are protobufs - will be of use).

We need to think a bit more on how we would set the testing up. Some ideas:

  • extend execbuild tests to include the physical planning step
  • extend the logic test harness so that instead of running the query once and checking the expected output, it would run the query with both planning modes and confirm that serialized physical plans are the same (fakedist configs will need to be skipped)
  • introduce some testing knob that would control whether the query is executed or a serialized physical plan is returned to the client (maybe we could have special EXPLAIN (EXPERIMENTAL_TEST) that would actually run the query twice with different factories and return ok/fail?) and have a roachtest that uses sqlsmith to generate queries .

Jira issue: CRDB-4112

@yuzefovich yuzefovich self-assigned this Jun 24, 2020
@yuzefovich yuzefovich added this to Triage in BACKLOG, NO NEW ISSUES: SQL Execution via automation Jun 24, 2020
@cockroachdb cockroachdb deleted a comment from blathers-crl bot Jun 24, 2020
@yuzefovich
Copy link
Member Author

cc @asubiotto if you have some ideas.

@asubiotto asubiotto moved this from Triage to 20.2 Commitments in BACKLOG, NO NEW ISSUES: SQL Execution Jun 30, 2020
@asubiotto asubiotto moved this from 20.2 Commitments to 20.2 C REACTIVE in BACKLOG, NO NEW ISSUES: SQL Execution Jul 7, 2020
@asubiotto asubiotto moved this from 20.2 C REACTIVE to 20.2 D in BACKLOG, NO NEW ISSUES: SQL Execution Jul 7, 2020
@asubiotto asubiotto moved this from 20.2 D to [GENERAL BACKLOG] Enhancements/Features/Investigations in BACKLOG, NO NEW ISSUES: SQL Execution Aug 4, 2020
@asubiotto asubiotto moved this from [GENERAL BACKLOG] Enhancements/Features/Investigations to 21.1 Possible Issues in BACKLOG, NO NEW ISSUES: SQL Execution Sep 3, 2020
@asubiotto asubiotto moved this from 21.1 Possible Issues to [GENERAL BACKLOG] Enhancements/Features/Investigations in BACKLOG, NO NEW ISSUES: SQL Execution Sep 30, 2020
@yuzefovich yuzefovich added this to Triage in SQL Queries via automation Apr 28, 2021
@yuzefovich yuzefovich removed this from [GENERAL BACKLOG] Enhancements/Features/Investigations in BACKLOG, NO NEW ISSUES: SQL Execution Apr 28, 2021
@yuzefovich yuzefovich moved this from Triage to 21.2 in SQL Queries Apr 28, 2021
@jlinder jlinder added the T-sql-queries SQL Queries Team label Jun 16, 2021
@yuzefovich yuzefovich moved this from 21.2 High Likelihood (90%) to 21.2 Low Likelihood (10%) in SQL Queries Jul 20, 2021
@jordanlewis jordanlewis assigned cucaroach and unassigned yuzefovich Nov 8, 2021
@cucaroach cucaroach moved this from 22.1 Low Likelihood (10%) to 22.1 High Likelihood (90%) in SQL Queries Jan 6, 2022
@rytaft rytaft moved this from 22.1 High Likelihood (90%) to Backlog in SQL Queries May 13, 2022
Copy link

We have marked this issue as stale because it has been inactive for
18 months. If this issue is still relevant, removing the stale label
or adding a comment will keep it active. Otherwise, we'll close it in
10 days to keep the issue queue tidy. Thank you for your contribution
to CockroachDB!

@yuzefovich yuzefovich added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) and removed no-issue-activity labels Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-queries SQL Queries Team
Projects
Status: Backlog
SQL Queries
Backlog (DO NOT ADD NEW ISSUES)
Development

No branches or pull requests

3 participants