8000 improve query plan serialization time by jsteemann · Pull Request #17897 · arangodb/arangodb · GitHub
[go: up one dir, main page]

Skip to content

improve query plan serialization time #17897

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

Merged
merged 1 commit into from
Jan 6, 2023

Conversation

jsteemann
Copy link
Contributor
@jsteemann jsteemann commented Jan 6, 2023

Scope & Purpose

Improve query plan serialization time

  • Added new stage "instantiating executors" to the query profiling output. The time spent in "instantiating executors" is the time needed to create the query executors from the final query execution time. In cluster mode, this stage also includes the time needed for physically distributing the query snippets to the participating database servers. Previously, the time spent for instantiating executors and the physical distribution was contained in the "optimizing plan" stage, which was misleading.

  • Remove constant values for query variables from query plan serialization in cases they were not needed. Previously, constant values of query variables were always serialized for all occurrences of a variable in a query plan. If the constant values were large, this contributed to higher serialization and thus query setup times. Now the constant values are only serialized for relevant parts of query execution plans.

The relevant change in this PR that has the largest effect on performance is that the toVelocyPack(...) method of aql::Variable now doesn't include constant values anymore. There is new overload of that method that will also include constant values, but it has to be called explicitly. This is now done only in a few dedicated places. All other places that call toVelocyPack(...) will call the method that doesn't serialize the constant values.
The rest of this PR contains a bit of cleanup, which is not relevant for the performance improvement.

  • 💩 Bugfix
  • 🍕 New feature
  • 🔥 Performance improvement
  • 🔨 Refactoring/simplification

Checklist

  • Tests
    • Regression tests
    • C++ Unit tests
    • integration tests
    • resilience tests
  • 📖 CHANGELOG entry made
  • 📚 documentation written (release notes, API changes, ...)
  • Backports

Related Information

  • Docs PR:
  • Enterprise PR:
  • GitHub issue / Jira ticket:
  • Design document:

* Added new stage "instantiating executors" to the query profiling output.
  The time spent in "instantiating executors" is the time needed to create
  the query executors from the final query execution time. In cluster mode,
  this stage also includes the time needed for physically distributing the
  query snippets to the participating database servers.
  Previously, the time spent for instantiating executors and the physical
  distribution was contained in the "optimizing plan" stage, which was
  misleading.

* Remove constant values for query variables from query plan serialization
  in cases they were not needed. Previously, constant values of query variables
  were always serialized for all occurrences of a variable in a query plan.
  If the constant values were large, this contributed to higher serialization
  and thus query setup times. Now the constant values are only serialized
  for relevant parts of query execution plans.
@jsteemann jsteemann added this to the devel milestone Jan 6, 2023
@cla-bot cla-bot bot added the cla-signed label Jan 6, 2023
Copy link
Contributor
@maierlars maierlars left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jsteemann jsteemann merged commit 114b453 into 7BF9 devel Jan 6, 2023
@jsteemann jsteemann deleted the bug-fix/improve-query-plan-serialization-time branch January 6, 2023 18:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0