2014-04-10 5:50 GMT+02:00 Amit Kapila <amit.kapil...@gmail.com>: > On Tue, Apr 8, 2014 at 9:07 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > 2014-04-08 6:27 GMT+02:00 Amit Kapila <amit.kapil...@gmail.com>: > >> So do you want to just print lock time for error'd statements, won't > >> it better to > >> do it for non-error'd statements as well or rather I feel it can be more > >> useful > >> for non-error statements? Do we already have some easy way to get > >> wait-time > >> for non-error statements? > > > > > > There are two points: > > > > a) we have no a some infrastructure how to glue some specific info to any > > query other than log_line_prefix. > > Can't we do that by using log_duration and log_min_duration_statement? > For Example, if I enable these parameters, below is the log: > > LOG: duration: 343.000 ms statement: create table t1(c1 int); >
yes, sorry. You have true. I though about this possibility, and I choose log_line_prefix due simple configurability and better parserability. But again, enhancing log_duration feature can be implement together with enhancing log_line_prefix. I'll try to visualise in prototype. Regards Pavel > > > And I have no any idea, how and what > > implement better. And I don't think so any new infrastructure > (mechanism) is > > necessary. log_line_prefix increase log size, but it is very well > parseable > > - splunk and similar sw has no problem with it. > > One thing that could happen if we implement total lock time at > log_line_prefix is that if user enables log_lock_waits, then it will start > printing duration for each lock wait time, not sure again it depends on > implementation. > > > b) lock time can be interesting on error statements too - for example - > you > > can cancel locked queries - so you would to see a lock time and duration > for > > cancelled queries. So this implementation can be sensible too. > > Agreed, I just said it will be quite useful for non-error'd long running > statements as well, so it might be good idea to see if we can implement > it for successful statements as well. > > > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com >
