Improving Memory Efficiency in Mutations with Short-Lived Cache for Concurrent Queries

If we run a mutation with IN (subquery) like this: ALTER TABLE t UPDATE col='new value' WHERE id IN (SELECT id FROM huge_table) and the table t has multiple parts than for each part a set for subquery SELECT id FROM huge_table is built in memory. And if there are many parts then this might consume a lot of memory (and lead to an OOM) and CPU. The solution is to introduce a short-lived cache of sets that are currently being built by mutation tasks. If another task of the same mutation is executed concurrently it can look up the set in the cache, wait for it to be built and reuse it. #46835 (Alexander Gololobov).