[Rpm-maint] [rpm-software-management/rpm] Won't recent Auto-Vaccum feature in RPM be perceived as a major performance regression by users? (Issue #3519)

[AnonymousCoward128746]

Moving this here to as a place for discussion. @ffesti  @pmatilai 

#3452 introduced an Auto-VACCUM threshold into rpm. (I learned of this change via https://github.com/rpm-software-management/dnf5/issues/2002)

I'm concerned about this change introducing a non-deterministic of latency into everyday package management operations. In my experience users hate non-deterministic response times and may perceive it as a significant regression.

LLM says that
```
The SQLite VACUUM operation is not incremental; it is a complete operation that rebuilds the entire database file.
```
so vacuuming a recently vacuumed database takes just as much time (ignoring effects of a possibly hot page cache), For spinning rust, this actually matters, while for 2000MB/s SSDs (where the rebuild may be quite quick) the bloat isn't noticeable to begin with.

Scenarios:
1. Imagine for example that some automated flow puts the db just at the tipping point. This might be a CI docker image build for example. The first install command for 10 million users who use CI actions on github now takes 10 times as long.
2. Can the user activate this cleanup multiple times, depending on the order they issue install/remove commands?
Can "rpm -i ABC; rpm -i XYZ" cause two cleanups while "rpm -i ABCXYZ" incurs the overhead only once? might users have to pay the cost of a rebuild multiple times in one session? 
3. Can some automated testing loops incur the rebuild on every iteration, with enough I/O in the meantime to evict the database data from the page cache?

Doesn't this make more sense as a cron job by distros? how do major distros usually handle periodic cleanup jobs like this? perhaps all they need is a hook to call. So that RPM can report if it needs to rebuild but the distro decides when:  "mechanism, not policy".

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3519
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/3519 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250113/1584ae57/attachment.htm>