Re: pg_stat_statements max size clarification

On Sat, Jul 15, 2017 at 5:31 PM, <baron(at)xaprb(dot)com> wrote:
> I wonder if &quot;least-executed&quot; is correct. I&#39;m not an expert and haven&#39;t
> convinced myself of this by examining the code, but I think after N distinct
> queryid&#39;s have been seen, then any additional ones are ignored. But that may
> not be &quot;least-executed&quot; at all. It&#39;s &quot;most-recent&quot; instead. I think we need
> a new phrase here.

It's most executed since tracking for the entry began, with a special
heuristic for queries that take a long time to execute, and might
therefore consistently be evicted before execution finishes and costs
are tallied (see "sticky entries" stuff for full details). Most
executed means the total number of calls, which may not be the best
thing to evict on the basis of, but certainly isn't too bad.

The way it actually works is that either 5% of all entries or 10
entries are evicted (whichever amount is greatest) once
pg_stat_statements.max entries are reached. You're right that this
means that the most marginal of entries cannot be usefully tracked,
but I doubt that that's much of a problem in practice. It's the usual
"recency versus frequency" cache eviction problem, but for query cost
tracking purposes if 5,000 entries or 10,000 entries is truly
insufficient, then pg_stat_statements probably isn't the right tool.

When that many entries seem insufficient that tends to be because
pg_stat_statements is arguably too discriminating about what
constitutes a distinct query/entry, but that's another problem.

--
Peter Geoghegan