Re: pg_stat_lwlocks view - lwlocks statistics, round 2

2012/10/20 2:45, Tom Lane wrote:
> Satoshi Nagayasu <snaga@uptime.jp> writes:
>> Ok, I guess we have reached the consensus to have
>> "some flight-recorder". Right?
> 
> I remain unconvinced.  I think the argument that this will promote
> novice understanding is complete hogwash: making any sense of
> lwlock-level stats will require deep PG understanding, not create it.
> And despite Jeff's optimistic views upthread, I don't think very many
> people have or will acquire such understanding.  So I'm really resistant
> to accepting even minimal overhead in pursuit of this goal --- and I
> do not believe the overhead will be minimal, either.

As I wrote "some", I'm actually not pushing "lwlock stat" itself
in this context, I still believe it would be useful though.
(I don't think it would be hogwash, because I needed it.)

I'm just thinking of how to help DBA understand PostgreSQL behavior
without deep dive into the code when he/she faces some kind of
performance issue, and also how to make it easier to help newbies
by PG experts, including tech support people.

As I posted before, I did an investigation on WAL performance when
I faced with random commit delays, and I found some problem on the
storage device by observing WALInsertLock and WALWriteLock statistic
with using SystemTap.

How could I do that without SystemTap on the production database?
SystemTap would kill performance (more than my patch), and sometimes
process, too.

Do you really think that we do not need any kind of lock statistic
anymore?

Regards,
-- 
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp