2014-04-17 7:12 GMT+02:00 Amit Kapila <amit.kapil...@gmail.com>: > On Mon, Apr 14, 2014 at 6:27 PM, Robert Haas <robertmh...@gmail.com> > wrote: > > I agree. I don't think the idea of pushing this into the > > log_line_prefix stuff as a one-off is a very good one. Sure, we could > > wedge it in there, but we've got an existing precedent that everything > > that you can get with log_line_prefix also shows up in the CSV output > > file. And it's easy to imagine LOTS more counters that somebody might > > want to have. Time spent planning, time spent executing, time spent > > waiting for disk I/O, time spent returning results to client, and I'm > > sure people will think of many others. I think this will balloon out > > of control if we don't have a more systematic design for this sort of > > thing. > > Can't we think of some infrastructure similar to what is done for > log_duration and log_min_duration_statement? > Current it prints like below: > LOG: duration: 343.000 ms statement: create table t1(c1 int); > > Let us say if user wants to track lock wait time a statement has > spent, then enable some config parameter (either log_lock_duration > or some other convenient way) > > LOG: lock duration: 'x' ms statement: create table t1(c1 int); >
isn't it log_line_prefix analogy? We can introduce new feature without hard dependency on CSV format I am thinking so there are clean requests: simply parseable - vector of numbers is ideal simply activated, deactivated - maybe list of flags in GUC Regards Pavel > > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com >
