From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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 02:43:10 |
Message-ID: | 56C3DE3E.1000705@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
What I think would be far more useful is adding lock wait time info to
pg_stat_statements and maybe pg_stat_*_tables.
--
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 | Amit Langote | 2016-02-17 02:56:27 | Re: Declarative partitioning |
Previous Message | Jim Nasby | 2016-02-17 02:32:47 | Re: [patch] Proposal for \crosstabview in psql |