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.
> and also add a sample test hook that can be > used to target statements of interest more narrowly (using a C hook > function).
You'd have to be pretty desperate, *and* knowledgeable, to write a C function for that. Can't we invent something a bit more user-friendly for the purpose? No idea what it should look like though.
I've been that desperate.
For the majority of users I'm sure it's sufficient to just have a sample rate.
Anything that's trying to match individual queries could be interested in all sorts of different things. Queries that touch a particular table being one of the more obvious things, or queries that mention a particular literal. Rather than try to design something complicated in advance that anticipates all needs, I'm thinking it makes sense to just throw a hook in there. If some patterns start to emerge in terms of useful real world filtering criteria then that'd better inform any more user accessible design down the track.
same method can be interesting for interactive EXPLAIN ANALYZE too. TIMING has about 20%-30% overhead and usually we don't need a perfectly exact numbers