2016-02-17 3:43 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 2/14/16 11:24 AM, Pavel Stehule wrote: > >> > We have a patch, that inject logs about the time waiting on locks >> before >> > query execution. This feature helps us lot of, and I hope, it can be >> > generally useful. >> >> Doesn't log_lock_waits cover that territory already? >> >> It does. But It creates different log entry - and can be hard to join >> slow query with log entry sometimes lot of lines before. This proposal >> is about taking important information comfortably - and log parsing and >> processing is simpler. >> > > I'm all for anything that improves visibility into locking, but it seems > like this is more a band-aid than a fix. Certainly any real analysis of > logfiles means you're stuck with something like pgBadger. If this would > significantly simply pgBadger's job then great, but I don't think that's > the case. > > What would be useful logging-wise is if the log line for the query itself > could contain lock wait time, but that doesn't sound like what you're > proposing? >
I hope, so I propose this idea. First time I wanted talk about the idea. Next step is the talk about format. > > What I think would be far more useful is adding lock wait time info to > pg_stat_statements and maybe pg_stat_*_tables. If we can enhance primary log, auto_explain, then we can do same with pg_stat_statements. lock statistics in table or database level would be great - it is good simple indicator about application health, but it is for another proposal (and patch). I can propose it, or I can collaborate on it with pleasure. Regards Pavel > > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com >
