Re: four minor proposals for 9.5
От | Amit Kapila |
---|---|
Тема | Re: four minor proposals for 9.5 |
Дата | |
Msg-id | CAA4eK1J_VX7eZDhzdbA=Mnte374dEbPvskb0PNZ89yehFH0eoQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: four minor proposals for 9.5 (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: four minor proposals for 9.5
|
Список | pgsql-hackers |
On Tue, Apr 8, 2014 at 9:07 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > 2014-04-08 6:27 GMT+02:00 Amit Kapila <amit.kapila16@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); > 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
В списке pgsql-hackers по дате отправления: