Re: proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time
Дата
Msg-id CAFj8pRC2Ldm=Xt64dE0zi59NYkLPBXs0AnVTwQ8fsLF3P8iRCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers


2016-02-17 3:43 GMT+01:00 Jim Nasby <Jim.Nasby@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tim Abbott
Дата:
Сообщение: Re: tsearch_extras extension
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl