> No, the entries are not removed randomly. We track "usage" for each
> entry (essentially +1 for each time the query got executed, with a decay
> factor applied on each eviction (and we evict 5% at a time).
OK I apologize, I hadn't looked in source code in details, and effectively
the "Usage" algorithm based on execution_time and calls will keep the
longest queries (and that's a good thing). In some cases (after an
application release or a postgres patch for exemple) we may be interested
in leastiests ones.
I'm still convinced that adding those kinds of informations
(with a planid as done in pg_stat_plans) would be an improvement.
Maybe because having used v$sql, first_load_time, last_active_time
and plan_hash_value for (too) many years).
It's always important to know when a new plan (good or bad) occurs, and pgss
give this kind of informations even without aggregation collector.
Last point (for developer), after testing this patch, in most cases when
calls=1: created and
last_updated values are identical, they don't even differ to reflect
execution (nor planing) duration. Is that a precision or coding problem ?
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html