> 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 could 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 ? Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
