In MDEV-25341 and MDEV-24670 there are options for explicitly asking the MariaDB server to release its memory.

The purpose of releasing memory is to be co-operative in cloud environments, shared hosting and other memory constrained areas. Activities like VM migration could also pre-trigger this SQL interface to avoid saving/migrating/restoring/tracking memory that isn't used.

In the automated (MDEV-24670), there are two levels in Linux ("some" and "full") and a single low memory Windows notification. By mirroring these functions on two levels provides the ability of the user to test what MariaDB impacts occur during memory pressure.

As each storage engine (and non-storage like thread pool) can cache/uncache in various ways, perhaps a storage engine optional handler function call can make available such mechanism.

On the SQL interface rather than a system variable, suggest FLUSH [FULL] UNUSED MEMORY could trigger the handler interfaces in the same way that the automated mechanism (MDEV-24670) does for consistency (and provide availability to non-Linux, non-Windows users).

What a basic vs full flush will largely depend on storage engine. To aid the differentiation inspired by marko maybe a global variable of recently_cached=600 as the number of seconds to consider recent. A "basic" flush will purge unused caches over this time and "full" can venture significantly less than this user controlled threshold to a minium defined by the storage engine.