-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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: fix logic to collect stats on system.jobs #108139
Conversation
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
This commit fixes an oversight in cockroachdb#102637 which intended to enable stats collection on the jobs table, but was not successful. I've manually confirmed that stats are now collected on the jobs table in a local cluster: ``` 888074673664065537 | AUTO CREATE STATS | Table statistics refresh for system.public.jobs | CREATE STATISTICS __auto__ FROM [15] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root | succeeded | NULL | 2023-08-03 19:01:22.343 ``` Informs cockroachdb#107405 Release note (performance improvement): We now automatically collect table statistics on the system.jobs table, which will enable the optimizer to produce better query plans for internal queries that access the system.jobs table. This may result in better performance of the system. Note: a previous attempt to enable stats on system.jobs starting in 23.1.0 was unsuccessful, but we have now fixed the oversight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. That shouldn't affect the query in #107405 though, right?
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @mgartner)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @mgartner)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build failed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Known flake: #108221
bors r+
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @mgartner)
Build failed (retrying...): |
Build failed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build failed: |
bors r+ |
Build succeeded: |
I think it does. That query uses the internal executor AFAIK. |
I see -- looks like you're right. In that case, probably not worth backporting this change. |
I think once we have a root cause for #102954 we can re-evaluate backporting. |
This commit fixes an oversight in #102637 which intended to enable stats collection on the jobs table, but was not successful.
I've manually confirmed that stats are now collected on the jobs table in a local cluster:
Informs #107405
Release note (performance improvement): We now automatically collect table statistics on the
system.jobs
table, which will enable the optimizer to produce better query plans for internal queries that access thesystem.jobs
table. This may result in better performance of the system. Note: a previous attempt to enable stats onsystem.jobs
starting in 23.1.0 was unsuccessful, but we have now fixed the oversight.