Re: [PROPOSAL] timestamp informations to pg_stat_statements

> 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