storage,schema: live bytes not updated immediately in response to TRUNCATE/DROP TABLE

[petermattis]

The "live bytes" count is not adjusted immediately when performing a TRUNCATE or DROP TABLE, though it is adjusted when performing a DELETE. This discrepancy can cause user confusion and is also somewhat problematic for Serverless as the only method to quickly reclaim "live bytes" is to use DELETE FROM. Even more problematic, if a user truncates a table then they can no longer reclaim those "live bytes" until the GC window has passed. For example:

CREATE TABLE foo (k int primary key);
-- MVCC Live Bytes/Count:  0 B / 0 count

Now insert some data into this table, and then DELETE it.

INSERT INTO foo (SELECT generate_series(1, 100000));
-- MVCC Live Bytes/Count:  7.1 MiB / 100000 count
DELETE FROM foo WHERE true;
--  MVCC Live Bytes/Count:  0 B / 0 count

As expected, the live bytes dropped to zero. Let's try that again with TRUNCATE:

INSERT INTO foo (SELECT generate_series(1, 100000));
-- MVCC Live Bytes/Count:  7.1 MiB / 100000 count
TRUNCATE foo;
-- MVCC Live Bytes/Count:  7.1 MiB / 100000 count

Tagging both Storage and Schema on this, as I think Schema would need to send an RPC to Storage to indicate that the data is data and we're simply waiting on the GC window to pass. This also ties into the MVCC DeleteRange ideas floating around, though perhaps this issue should be fixed separately.

Jira issue: CRDB-10680

[ajwerner]

This is an artifact of previously not having an MVCC-compliant, efficient DelRange and only having a non-MVCC ClearRange. The SQL layer hacked around this by waiting out the GC TTL above KV and then issuing ClearRange over the span. LiveBytes is a KV metric and KV had no way to know that those bytes are now garbage. The issue which will fix this UX problem is #70427. We're moving on these problems in this release.

[postamar]

Now that we have DelRange, can we address this?

[ajwerner]

Yes, this will be addressed as soon as we ship the DelRange changes in 23.1. I think we can close this as fixed by #85878 and #91146.