-
Denis Smirnov authored
Previously we cached only the leaf sub-trees of the IR plan under the first level of motions. The problem was in temporary tables as we used random names for them and dropped after usage (and invalidated corresponding prepared statements as well). Now we use idempotent names for temporary tables and truncate them after usage. It allows us to keep prepared statements in the cache. One more thing: as we use the same temporary table for multiple queries, we need to use latch locks for the prepared statement cache. One day we'll switch to more granular locks (mostly for vinyl spaces), but let's use current approach for the start. We also removed can_be_cached flag from the code. Only DQL uses VDBE and needs caching, and all these queries can be cached. The only exception are the queries with Local and LocalSegment motion policies but only DML can have them. So, no need for this flag and let's make the code cleaner.
Denis Smirnov authoredPreviously we cached only the leaf sub-trees of the IR plan under the first level of motions. The problem was in temporary tables as we used random names for them and dropped after usage (and invalidated corresponding prepared statements as well). Now we use idempotent names for temporary tables and truncate them after usage. It allows us to keep prepared statements in the cache. One more thing: as we use the same temporary table for multiple queries, we need to use latch locks for the prepared statement cache. One day we'll switch to more granular locks (mostly for vinyl spaces), but let's use current approach for the start. We also removed can_be_cached flag from the code. Only DQL uses VDBE and needs caching, and all these queries can be cached. The only exception are the queries with Local and LocalSegment motion policies but only DML can have them. So, no need for this flag and let's make the code cleaner.