Craig Ringer <craig@2ndquadrant.com> writes: > It's sometimes desirable to collect auto_explain data with ANALYZE in order > to track down hard-to-reproduce issues, but the performance impacts can be > pretty hefty on the DB.
> I'm inclined to add a sample rate to auto_explain so that it can trigger > only on x percent of queries,
That sounds reasonable ...
Cool, I'll cook that up then. Thanks for the sanity check.
OK, here we go.
To make sure it doesn't trigger on all backends at once, and to ensure it doesn't rely on a shared point of contention in shmem, this sets up a counter with a random value on each backend start.
Because it needs to either always run both the Start and End hooks, or run neither, this doesn't count nested statements for sampling purposes. So if you run my_huge_plpgsql_function() then either all its statements will be explained or none of them will. This only applies if nested statement explain is enabled. It's possible to get around this by adding a separate nested statement counter that's reset at each top level End hook, but it doesn't seem worthwhile.
The sample rate has no effect on ANALYZE, which remains enabled or disabled for all queries. I don't see any point adding a separate sample rate control to ANALYZE only some sub-proportion of EXPLAINed statements.
