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

Reduce Log Level for Compress Chunk #7280

Closed
gmilamjr opened this issue Sep 18, 2024 · 0 comments · Fixed by #7335
Closed

Reduce Log Level for Compress Chunk #7280

gmilamjr opened this issue Sep 18, 2024 · 0 comments · Fixed by #7335
Labels
enhancement An enhancement to an existing feature for functionality

Comments

@gmilamjr
Copy link

What type of enhancement is this?

Other

What subsystems and features will be improved?

Other

What does the enhancement do?

Reduce the log volume generated by the compress_chunk function. Currently, we have a maintenance job that processes existing chunks and calls the compress_chunk function as needed. This operation produces a significant amount of output in the PostgreSQL server log at the current LOG level, leading to excessive log volume. Would it make sense to lower the log level from LOG to INFO? Otherwise, suppressing the output would require setting the log_min_messages to FATAL.

Implementation challenges

No response

@gmilamjr gmilamjr added the enhancement An enhancement to an existing feature for functionality label Sep 18, 2024
@bearpaws
Copy link

bearpaws commented Oct 7, 2024

On 2.15.2 I am seeing massive amounts of these log entries when compressing chunks:

2024-10-07 19:29:14.626 UTC: @,app= LOG:  finished compressing 177 rows from "_hyper_3636_79259_chunk"

I don't believe this was happening in previous versions.

@bearpaws
Copy link

bearpaws commented Oct 7, 2024

It was introduced here 28d3a5f

Note the comment from @nikkhils "We can re-look if the users complaint about the chattiness later."

@bearpaws
Copy link

bearpaws commented Oct 8, 2024

Here's an example of a complete call to compress_chunk with all the lines we think should be logged at DEBUG instead of LOG:

2024-10-08 18:30:07.563 UTC: @,app= LOG:  acquiring locks for compressing "_timescaledb_internal._hyper_3140_95813_chunk"
2024-10-08 18:30:07.563 UTC: @,app= LOG:  locks acquired for compressing "_timescaledb_internal._hyper_3140_95813_chunk"
2024-10-08 18:30:07.699 UTC: @,app= LOG:  new compressed chunk "_timescaledb_internal.compress_hyper_3141_96059_chunk" created
2024-10-08 18:30:07.699 UTC: @,app= LOG:  using tuplesort to scan rows from "_hyper_3140_95813_chunk" for compression
2024-10-08 18:30:09.638 UTC: @,app= LOG:  compressed 232206 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:09.723 UTC: @,app= LOG:  compressed 464412 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:09.799 UTC: @,app= LOG:  compressed 696618 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:09.884 UTC: @,app= LOG:  compressed 928824 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:09.963 UTC: @,app= LOG:  compressed 1161030 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:10.045 UTC: @,app= LOG:  compressed 1393236 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:10.118 UTC: @,app= LOG:  compressed 1625442 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:10.190 UTC: @,app= LOG:  compressed 1857648 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:10.259 UTC: @,app= LOG:  compressed 2089854 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:10.332 UTC: @,app= LOG:  compressed 2322060 rows from "_hyper_3140_95813_chunk"
2024-10-08 18:30:10.359 UTC: @,app= LOG:  finished compressing 2406720 rows from "_hyper_3140_95813_chunk"

svenklemm added a commit to svenklemm/timescaledb that referenced this issue Oct 9, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes timescale#7280
svenklemm added a commit to svenklemm/timescaledb that referenced this issue Oct 9, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes timescale#7280
svenklemm added a commit to svenklemm/timescaledb that referenced this issue Oct 9, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes timescale#7280
svenklemm added a commit to svenklemm/timescaledb that referenced this issue Oct 9, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes timescale#7280
svenklemm added a commit to svenklemm/timescaledb that referenced this issue Oct 9, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes timescale#7280
svenklemm added a commit that referenced this issue Oct 9, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes #7280
@antekresic antekresic added force-auto-backport Automatically backport this PR or fix of this issue, even if it's not marked as "bug" and removed force-auto-backport Automatically backport this PR or fix of this issue, even if it's not marked as "bug" labels Oct 18, 2024
antekresic pushed a commit that referenced this issue Oct 18, 2024
Don't use LOG log level when printing out non-actionable progress
information regarding compression.

Fixes #7280

(cherry picked from commit 8775c84)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement to an existing feature for functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants