Remove recommendations to use crdb_internal.mvcc_timestamp in favor of ON UPDATE

[vy-ton]

Once we support ON UPDATE in hopefully 21.2, we should remove recommendations to use crdb_internal.mvcc_timestamp in favor of an ON UPDATE example.

Pages:

• https://www.cockroachlabs.com/docs/v21.1/bulk-delete-data.html#batch-delete-expired-data

[vy-ton]

@ericharmeling Can you get to this in the next 2 weeks?

[ericharmeling]

@ericharmeling Can you get to this in the next 2 weeks?

Yes! Will aim for EOW.

[vy-ton]

@mwang1026 What's the full story with crdb_internal_mvcc_timestamp? Do you think we should remove all mentions of it in our docs? Or strongly indicate that the internals could change that are unexpected for users?

[mwang1026]

The latter is a must if we keep it around.

I think it'd be abrupt to remove it, if people rely on it, so I say we keep it for now with the major caveat

[ericharmeling]

I've extended the note on crdb_internal_mvcc_timestamp: #12033

I'll leave this issue open to track a recommendation to use ON UPDATE for TTL instead.

[ericharmeling]

@vy-ton

we should remove recommendations to use crdb_internal.mvcc_timestamp in favor of an ON UPDATE example.

Is the recommendation here to create a new TIMESTAMPTZ column with a now() ON UPDATE expression (e.g., ALTER TABLE ... ADD COLUMN last_updated TIMESTAMPTZ DEFAULT now() ON UPDATE now();), index the column, and then follow the indexed batch-delete pattern when deleting expired data?

[vy-ton]

I believe you want a hash-sharded index for the timestamptz column