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

sql: Enhance jobs details for row-level TTL deletion jobs #79916

Closed
vy-ton opened this issue Apr 13, 2022 · 5 comments
Closed

sql: Enhance jobs details for row-level TTL deletion jobs #79916

vy-ton opened this issue Apr 13, 2022 · 5 comments
Assignees
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@vy-ton
Copy link
Contributor

vy-ton commented Apr 13, 2022

Problem:
When a user has multiple tables configured with row-level TTL, the job description/details does not indicate what table is undergoing deletion. The SQL Activity page also does not include statements for the internal queries to find and delete expired rows.

image

Another example where table information is needed: when sql.ttl.job.enabled=false
image

Expected behavior:

  • Can the deletion jobs description/details include the statements to find/deleted expired rows? What exactly did the database run for users.
  • Queries to find expired rows and DELETE statements from TTL deletion jobs will show up with the $ internal application name on the SQL activity page

Epic CRDB-14592

Jira issue: CRDB-15726

@vy-ton vy-ton added the C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. label Apr 13, 2022
@blathers-crl blathers-crl bot added the T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) label Apr 13, 2022
@otan
Copy link
Contributor

otan commented Apr 13, 2022

Can the deletion jobs description/details include the statements to find/deleted expired rows? What exactly did the database run for users.

not sure

Queries to find expired rows and DELETE statements from TTL deletion jobs will show up with the $ internal application name on the SQL activity page

that's a different issue and likely something we'll need to ask queries about - not sure why internal executor queries do not show up on that page.

@rafiss
Copy link
Collaborator

rafiss commented Apr 13, 2022

Queries to find expired rows and DELETE statements from TTL deletion jobs will show up with the $ internal application name on the SQL activity page.

More of a sql-observability issue: #79547

@otan
Copy link
Contributor

otan commented Apr 13, 2022

Can the deletion jobs description/details include the statements to find/deleted expired rows? What exactly did the database run for users.
Queries to find expired rows and DELETE statements from TTL deletion jobs will show up with the $ internal application name on the SQL activity page

This will be the case when #79547 is addressed. - I'm closing this issue in favour of that for now.

I've added #79927 to make the "jobs" more identifiable, which will display nicely once we have #79547 addressed. In the meantime, SHOW STATEMENTS is a workaround.

@vy-ton
Copy link
Contributor Author

vy-ton commented Apr 14, 2022

Even with #79547, there's not a way to connect statements to the job that spawned them, right? Let's start with making the jobs more identifiable but I'll keep an eye out for whether user debugging requires more observability

@otan
Copy link
Contributor

otan commented Apr 14, 2022

#79927 does - the statement will display the table name as well in SHOW STATEMENTS

craig bot pushed a commit that referenced this issue Apr 18, 2022
79927: ttlschedule: include table name when creating the TTL job r=rafiss a=otan

Refs: #79916

Release note: None

79936: ui: add all jobs to jobs page filter r=maryliag a=otan

<img width="604" alt="image" src="https://user-images.githubusercontent.com/3646147/163288704-498f0de7-699a-48db-8667-9c7d63b0f8ef.png">

Resolves #79915

Release note (ui change): More jobs now shows up as a types filter
on the jobs page.

80115: kvcoord: bump default value of max_refresh_span_bytes to 4MB r=arulajmani a=arulajmani

We recently saw an escalation where the default value of
`kv.transaction.max_refresh_span_bytes` was causing degraded
performance. This patch bumps the default value for this setting to 4MB
bringing it in line with our recent change to
 `kv.transaction.max_intent_bytes`.

Release note (ops change): increase the default value of
`kv.transaction.max_refresh_span_bytes` from 256KB to 4MB.

80117: logictest: bump disk limit from 100MB to 512MiB r=yuzefovich a=yuzefovich

We have some queries that bump into 100MB default temp storage limit
when run with fakedist-disk config, so we'll use a larger limit now.
There isn't really a downside to doing so.

Fixes: #74554

Release note: None

80119: sql/schemachange: handle errors properly in element UML generator r=fqazi a=fqazi

Previously, the element UML generator did not properly deal
with errors from a WriteFile call, leading to linter errors
on master. This patch, address this issue by properly dealing
with the error from WriteFile.

Release note: None

Co-authored-by: Oliver Tan <[email protected]>
Co-authored-by: arulajmani <[email protected]>
Co-authored-by: Yahor Yuzefovich <[email protected]>
Co-authored-by: Faizan Qazi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
None yet
Development

No branches or pull requests

4 participants