On 8/13/14, 5:14 AM, MauMau wrote:
I'm interested in b, too. I was thinking of proposing a performance
diagnostics feature like Oracle's wait events (V$SYSTEM_EVENT and
V$SESSION_EVENT). So, if you do this, I'd like to contribute to the
functional design, code and doc review, and testing.
From: Alvaro Herrera alvhe...@2ndquadrant.com
Is this supposed to be session-local data, or is it visible from remote
sessions too? How durable is it supposed to be? Keep in mind that in
case of a crash, all pgstats data is erased.
I want it to be visible from other sessions. I'm okay about
2014-08-18 7:42 GMT+02:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Pavel Stehule wrote:
2014-08-13 15:22 GMT+02:00 MauMau maumau...@gmail.com:
I didn't mean performance statistics data to be stored in database
tables.
I just meant:
* pg_stat_system_events is a view to show data
Pavel Stehule wrote:
2014-08-13 15:22 GMT+02:00 MauMau maumau...@gmail.com:
I didn't mean performance statistics data to be stored in database tables.
I just meant:
* pg_stat_system_events is a view to show data on memory, which returns
one row for each event across the system. This
From: Pavel Stehule pavel.steh...@gmail.com
There are two relative independent tasks
a) monitor and show total lock time of living queries
b) monitor and log total lock time of executed queries.
I am interested by @b now. When we work with slow query log, then we would
to identify reason for
2014-08-13 11:14 GMT+02:00 MauMau maumau...@gmail.com:
From: Pavel Stehule pavel.steh...@gmail.com
There are two relative independent tasks
a) monitor and show total lock time of living queries
b) monitor and log total lock time of executed queries.
I am interested by @b now. When we
From: Pavel Stehule pavel.steh...@gmail.com
isn't it too heavy?
Are you concerned about the impactof collection overhead on the queries
diagnosed? Maybe not light, but I'm optimistic. Oracle has the track
record of long use, and MySQL provides performance schema starting from 5.6.
I have
2014-08-13 13:59 GMT+02:00 MauMau maumau...@gmail.com:
From: Pavel Stehule pavel.steh...@gmail.com
isn't it too heavy?
Are you concerned about the impactof collection overhead on the queries
diagnosed? Maybe not light, but I'm optimistic. Oracle has the track
record of long use, and
From: Pavel Stehule pavel.steh...@gmail.com
2014-08-13 13:59 GMT+02:00 MauMau maumau...@gmail.com:
Are you concerned about the impactof collection overhead on the queries
diagnosed? Maybe not light, but I'm optimistic. Oracle has the track
record of long use, and MySQL provides performance
2014-08-13 15:22 GMT+02:00 MauMau maumau...@gmail.com:
From: Pavel Stehule pavel.steh...@gmail.com
2014-08-13 13:59 GMT+02:00 MauMau maumau...@gmail.com:
Are you concerned about the impactof collection overhead on the queries
diagnosed? Maybe not light, but I'm optimistic. Oracle has the
On Wed, Aug 13, 2014 at 4:59 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Any idea how to show a lock time in some practical form together with logged
slow query?
Doing a join on pg_stat_activity and pg_locks is not going to help
much as you could only get the moment when query has started
Michael Paquier michael.paqu...@gmail.com writes:
Doing a join on pg_stat_activity and pg_locks is not going to help
much as you could only get the moment when query has started or its
state has changed. Have you thought about the addition of a new column
in pg_locks containing the timestamp
Hi
2014-08-13 6:18 GMT+02:00 Michael Paquier michael.paqu...@gmail.com:
On Wed, Aug 13, 2014 at 4:59 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Any idea how to show a lock time in some practical form together with
logged
slow query?
Doing a join on pg_stat_activity and pg_locks
2014-08-13 7:19 GMT+02:00 Tom Lane t...@sss.pgh.pa.us:
Michael Paquier michael.paqu...@gmail.com writes:
Doing a join on pg_stat_activity and pg_locks is not going to help
much as you could only get the moment when query has started or its
state has changed. Have you thought about the
14 matches
Mail list logo
