From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time |
Date: | 2016-02-17 04:07:41 |
Message-ID: | CAFj8pRC2Ldm=Xt64dE0zi59NYkLPBXs0AnVTwQ8fsLF3P8iRCg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-02-17 3:43 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-02-17 04:12:46 | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |
Previous Message | Tim Abbott | 2016-02-17 03:57:31 | Re: tsearch_extras extension |