8000 go: sqle/statspro: prollyStats: FlushFromMem: Fix long-held lock when flushing stats to disk. by reltuk · Pull Request #9236 · dolthub/dolt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

go: sqle/statspro: prollyStats: FlushFromMem: Fix long-held lock when flushing stats to disk. #9236

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
May 20, 2025
Merged

go: sqle/statspro: prollyStats: FlushFromMem: Fix long-held lock when flushing stats to disk. #9236

merged 1 commit into from
May 20, 2025

Conversation

reltuk
Copy link
Contributor
@reltuk reltuk commented May 20, 2025 •
edited
Loading

For sql-server instances with many databases, many branches or many tables and indexes, flushing stats could cause queries to block until stats were finished flushing. StatsController attempted to rate limited how much I/O bandwidth would be used to flush stats, but this is currently counter-productive because all queries are blocked from analyzing successfully until stats are flushed.

This changes it back to flush stats to disk as quickly as possible when we need to do it. Computing stats is already rate limited, so for large flushes this should not happen too often.

We will continue to improve things here so that stats writes have less impact on server resource utilization and do not block user-facing work as they proceed.

@reltuk
go: sqle/statspro: prollyStats: FlushFromMem: Fix long-held lock when…
a90a4bc 
… flushing stats to disk.

For sql-server instances with many databases, many branches or many tables
indexes, flushing stats could cause queries to block until stats were finished
flushing. StatsController attempted to rate limited how much I/O bandwidth
would be used to flush stats, but this is currently counter-prod
8000
uctive because
all queries are blocked from analyzing successfully until stats are flushed.

This changes it back to flush stats to disk as quickly as possible when we need
to do it. Computing stats is already rate limited, so for large flushes this
should not happen to often.

We will continue to improve things here so that stats writes have less impact
on server resource utilization and do not block user-facing work as they
proceed.
macneale4
macneale4 approved these changes May 20, 2025
View reviewed changes
Copy link
Contributor
@macneale4 macneale4 left a comment

Choose a reason for hiding this comment

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

              |    |    |
             )_)  )_)  )_)
            )___))___))___)\
           )____)____)_____)\\
         _____|____|____|____\\\__
---------\                   /---------
  ^^^^^ ^^^^^^^^^^^^^^^^^^^^^
    ^^^^      ^^^^     ^^^    ^^
         ^^^^      ^^^

@coffeegoddd
Copy link
Contributor

@reltuk DOLT

comparing_percentages
100.000000 to 100.000000
version result total
a90a4bc ok 5937457
version total_tests
a90a4bc 5937457
correctness_percentage
100.0

@reltuk reltuk merged commit 7058180 into main May 20, 2025
34 of 35 checks passed
@BrewTestBot BrewTestBot mentioned this pull request May 21, 2025
Merged
@tbantle22 tbantle22 deleted the aaron/statspro-long-lock-cleanup branch May 28, 2025 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@macneale4 macneale4 macneale4 approved these changes

Assignees
No one assigned
Labels
correctness_approved
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@reltuk @coffeegoddd @macneale4
0