Seems like a real rookie question – and it more or less is, coming from me. However I couldn’t find it answered anywhere.
Ever since I realized that deleted rows don’t go away completely as they retain their row ID, I was wondering if those deleted rows impact the performance of a doc.
So if I had a table with 100.000 rows of which 90.000 had been deleted after being archived elsewhere, would the performance hit be that of a table with 10.000 or 100.000 rows?
I am currently working on an archiving solution and if deleted rows impact performance because they are still present in the underlying database, the whole attempt seems a bit futile to me.
No, deleted rows won’t affect performance. Deleting table rows to speed up a slow doc is a pretty much a recommended practice at this point. There are a ton of methods to achieve this archival process, and there have been a good few posts here on the community about different solutions.
Row IDs are single-use by design, so cannot be reused or reissued to new rows even after a deletion event. That doesn’t mean that deleted rows are somehow still active in the background.
While deleted rows, once deleted, are immediately gone and by being gone should speed your doc up they do linger around in one manner.
Your docs have an api size limit. And once your doc reaches a certain size, it gets over the api size limit.
If a doc is over the api size limit and you delete 90,000 rows, you doc does not immediately fall back under the api size limit for example. Those rows do exist in a ghost like state in your doc and are not fully purged.
Deleted data is kept around in a few different ways in case a user wants to “undo” their way back to a non-deleted state.
Sometimes that deleted data is kept around for up to a month
But not in a way that effects the immediate performance of your doc
