Do not use vacuum when pruning

[KonradStaniec]

Removes usage of vacuum from fluffy pruning. With new approach fluffy node will reach specified maxDb size, and than stay with this size through its life time as pages freed by deleting items will be re-used for further additions.

Two follow up tasks are necessary:

1. Devise vacuum strategy - after few pruning cycles database can become fragmented which may impact performance, so at some point in time VACCUM will need to be run to defragment db.
2. Deal with edge case when user would configure max db size lower than
   current db.size(). With such config data base would try to prune iteslf with
   each addition

[kdeme]

Suggested change

	## Return size of pages which are used by databse, but are currently empty i.e
	## they can be re-used for new content
	## Returns the total size of the pages which are unused by the database,
	## i.e they can be re-used for new content.

[kdeme]

This can probably remain private?

[kdeme]

Suggested change

	# We use real size for our pruning treshold, which means that database file
	# We use real size for our pruning threshold, which means that database file

[kdeme]

Suggested change

	# will reach size specified in db.maxSize, and will stay that size thourough
	# will reach size specified in db.maxSize, and will stay that size thorough

[kdeme]

Suggested change

	# 1. Devise vacuum strategy - after few pruning cycles database can be
	# fragmented which may impact performance, so at some point in time `VACCUM`
	# will need to be run to defragment db.
	# 2. Deal with edge case when user would configre max db size lower than
	# current db.size(). With such config data base would try to prune iteslf with
	# each addition
	# 1. Devise vacuum strategy - after few pruning cycles database can become
	# fragmented which may impact performance, so at some point in time `VACUUM`
	# will need to be run to defragment the db.
	# 2. Deal with the edge case where a user configures max db size lower than
	# current db.size(). With such config the database would try to prune itself with
	# each addition.

[kdeme]

Two follow up tasks are necessary:

1. I think we don't need to solve this straight away, but lets create an issue for it. Not great UX, but perhaps for now a VACUUM could be called through a separate cli command or perhaps a json-rpc debug call
2. The simplest solution here is to just delete the existing database and create a new one when this scenario occurs. The other obvious solution is running VACUUM when this occurs, but then you hit the same issue as at 1. (size doubling briefly).

[KonradStaniec]

I think we don't need to solve this straight away, but lets create an issue for it. Not great UX, but perhaps for now a VACUUM could be called through a separate cli command or perhaps a json-rpc debug call

Agreed that for now it is not an urgent thing. I will create a task for it.

The simplest solution here is to just delete the existing database and create a new one when this scenario occurs. The other obvious solution is running VACUUM when this occurs, but then you hit the same issue as at 1. (size doubling briefly).

Deleting database sounds harsh, and would probably incur some unhappy users do not expecting such behaviour. (although we still do not have users yet so 😅 ) Probably the most comprehensive solution would be to have database in incremental vacuum mode, delete enough data so db size will drop to the half of provided new limit, then change db size by incremental delete pragma and then vacuum. That way are within limit all the time, and end up with correct database state. Drawback is that client start up can probably take a while when such thing happen.

[kdeme]

Deleting database sounds harsh, and would probably incur some unhappy users do not expecting such behaviour. (although we still do not have users yet so sweat_smile ) Probably the most comprehensive solution would be to have database in incremental vacuum mode, delete enough data so db size will drop to the half of provided new limit, then change db size by incremental delete pragma and then vacuum. That way are within limit all the time, and end up with correct database state. Drawback is that client start up can probably take a while when such thing happen.

Yes, I did call it the simplest solution, not the one with best UX. A more complex solution is for example what you mentioned. But, as you mention yourself already, when a user requests to use only half of the current storage that is being used now, it will practically keep only ~25% of their original database instead of ~50%. Better than a full reset, but still not great (And especially for small storage size settings, perhaps not worth it). The incremental vacuum setting will also increase the db overhead (although I don't know by how much, perhaps negligible).
We also need to ask the question whether it is an important use case to be able to lower to storage size originally set, that it is worth adding complexity / potential overhead. For now I wouldn't invest to much effort in it.

[KonradStaniec]

We also need to ask the question whether it is an important use case to be able to lower to storage size originally set, that it is worth adding complexity / potential overhead. For now I wouldn't invest to much effort in it.

Yep agree 👍 , for now maybe it would be enough to return error to the user in such case