Skip to content

Conversation

@Shubham8287
Copy link
Contributor

@Shubham8287 Shubham8287 commented Nov 12, 2025

Description of Changes

A background task to cleanup unsubscribed views.
fixes #3587

API and ABI breaking changes

NA

Expected complexity level and risk

2

Testing

Added a test

Signed-off-by: Shubham Mishra <[email protected]>
@Shubham8287 Shubham8287 changed the title views cleanup Views: cleanup unsubscribed views Nov 12, 2025
@Shubham8287 Shubham8287 self-assigned this Nov 12, 2025
Signed-off-by: Shubham Mishra <[email protected]>
@bfops bfops added the release-any To be landed in any release window label Nov 17, 2025
@Shubham8287
Copy link
Contributor Author

Test is better modularised in this PR - #3670.

Copy link
Collaborator

@joshua-spacetime joshua-spacetime left a comment

Choose a reason for hiding this comment

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

The approach makes sense. I just have a couple thoughts:

  1. I think we should be more conservative in how frequent we clean up views. I don't think our clean up intervals need to be on the order of seconds.

  2. Also we probably want to bound the length of time a cleanup job takes. If there are many old views, I think we'd rather clean them up in multiple jobs to avoid taking a tx lock for an extended period of time.

@Shubham8287
Copy link
Contributor Author

Shubham8287 commented Nov 20, 2025

  1. Also we probably want to bound the length of time a cleanup job takes. If there are many old views, I think we'd rather clean them up in multiple jobs to avoid taking a tx lock for an extended period of time.

Should it be limited by a hardcoded number (like 100 cleanups at a time) Or duration (atmost to take 5ms) or something else?

I feel limiting it to hardcoded number of views to cleanup can be a problem if continously more new views expires more than that number between job intervals.

@joshua-spacetime
Copy link
Collaborator

I agree, I think duration is the right metric. And we can even make that duration configurable later (not a requirement for this PR).

github-merge-queue bot pushed a commit that referenced this pull request Nov 20, 2025
# Description of Changes
Make View backing tables and related St tables not persistent.

1. Modifies `CommittedState` to hold set of ephemeral tables.
2. Update `TxData` to contain a subset of ephemeral tables which has
been modified in current transaction.

`do_durability` filter those table out before writting the transaction
to commitlog.

depends on: #3651
# API and ABI breaking changes
NA

# Expected complexity level and risk
2.5.

looks simple but changes comes in the hotpath, I ensured we don't do
unneccessary heap allocations but patch has the potential to regress
perfomance.


# Testing

- unit test.

---------

Signed-off-by: Shubham Mishra <[email protected]>
Co-authored-by: Mazdak Farrokhzad <[email protected]>
@Shubham8287 Shubham8287 added this pull request to the merge queue Nov 20, 2025
Any commits made after this event will not be merged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-any To be landed in any release window

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Clear materialized view tables async

4 participants