Skip to content

CASSANDRA-13001 Implement appender of slow queries to system_views.slow_queries table #4067

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

Open
wants to merge 2 commits into
base: trunk
Choose a base branch
from

Conversation

smiklosovic
Copy link
Contributor

patch by Stefan Miklosovic; reviewed by TBD for CASSANDRA-13001

Thanks for sending a pull request! Here are some tips if you're new here:

  • Ensure you have added or run the appropriate tests for your PR.
  • Be sure to keep the PR description updated to reflect all changes.
  • Write your PR title to summarize what this PR proposes.
  • If possible, provide a concise example to reproduce the issue for a faster review.
  • Read our contributor guidelines
  • If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

@smiklosovic smiklosovic requested a review from bschoening April 9, 2025 11:42
@smiklosovic smiklosovic force-pushed the CASSANDRA-13001 branch 7 times, most recently from a794d28 to 0437269 Compare April 9, 2025 13:02
@Override
public void truncate()
{
buffer.clear();
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it worth adding a debug logger message stating that the table has been truncated?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I dont think so, really.

{
// we restrict how many logging events we can put into buffer,
// so we are not growing without any bound when things go south
if (messageBuffer.size() < defaultRows)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we add a logger debug if message is not added to the buffer due to buffer size?

Copy link
Contributor Author

@smiklosovic smiklosovic Apr 22, 2025

Choose a reason for hiding this comment

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

That would most probably cause a flood of debug messages every time we are "over the limit" unless the logger is no-spamming one. I would keep it like it is.


execute(query("truncate %s"));

assertTrue(executeNet(query("select timestamp from %s")).all().isEmpty());
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use assertEmpty?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't see any simple way to do that because executeNet returns ResultSet from driver but assertEmpty accepts UntypedResultSet

patch by Stefan Miklosovic; reviewed by Dmitry Konstantinov, Bernardo Botella for CASSANDRA-13001
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants