You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This change attempts to resolve#2927 by introducing the ability
to VACUUM the database by:
- giving atuin-server-database the `vacuum` method. This simply calls
sqlx::query("VACUUM"). I also added a test, as we're using sqlx &
sqlite this test can be executed in memory. Sadly the same cannot
happen for postgres, but the test is kind of trivial.
- exposing a vacuum endpoint on the server. This handler calls vacuum.
This can be useful for users who wish to manually vacuum a db, but
this is not exposed via the CLI, instead...
- adding `auto_vacuum_threshold` option to the server configuration. If
`auto_vacuum_threshold` is > 0, then the server will increment the
`delete_count` atomic counter, and when this counter reached the
threshold it will call vacuum and reset the counter.
The default for `auto_vacuum_threshold` is `0` meaning "never vacuum",
but users can set this to a value which will come down to their
preference, guided by:
- How long they anticipate their server running for. For example
setting it to a high-ish number like 1000 would probably be appropriate
for a server running on a machine which has long uptimes. For self hosting
for a single user, this might be a little long though, keeping in
mind that if the server goes down (or the mahcine goes down) the counter will
reset to 0.
- For users who _really care_ about disk space and don't really care
about latency on deletes, setting to `1` will will vacuum on every
delete.
I considered adding some kind of "recommended" number but I don't think
there is a good number to unilaterally recommend for this.
0 commit comments