Re: four minor proposals for 9.5
От | Amit Kapila |
---|---|
Тема | Re: four minor proposals for 9.5 |
Дата | |
Msg-id | CAA4eK1JqjTk3x_BiPFnnN3Jti3_uFxg=DSFKc1wzdzS3X4AJMQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: four minor proposals for 9.5 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: four minor proposals for 9.5
|
Список | pgsql-hackers |
On Mon, Apr 14, 2014 at 6:27 PM, Robert Haas <robertmhaas@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); With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: