On 12/10/2011 09:28 PM, Craig Ringer wrote:
One thing I think would be interesting for this would be to identify slow queries (without doing detailed plan timing) and flag them for more detailed timing if they're run again within <x> time. I suspect this would only be practical with parameterised prepared statements where the query string remained the same, but that'd still be interesting
There are actually two patches sitting in the current PostgreSQL CommitFest that allow normalizing query strings in a way that they could be handled like this even if not prepared, as part of pg_stat_statements. What you're asking for is basically a hybrid of that and auto_explain, with something smarter deciding when the explain is triggered. Interesting idea, I hadn't thought of that heuristic before. It won't be hard to do if the query normalization stuff commits.
Personally I'd choose good performance monitoring over user/query priorities any day. With good perf monitoring I can script from the outside I have a lot more control, can send alerts, etc etc.
Luckily for you it's hard to do it in any other order. When I think about how we'd have to validate whether query prioritization code was operating as expected or not, I imagine some extra monitoring tools really need to get built first. Might as well expose those for people like yourself too, once they're built for that purpose.
-- Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
