Alvaro Herrera writes:
> Regarding Tom's objection to the fundamental issue of providing lwlocks
> data, I agree that maybe it's the wrong layer to be measuring to provide
> data to DBAs, but not providing any data is worse, because then even PG
> developers cannot know what are the real bottlenec
Robert Haas escribió:
> On Fri, Oct 19, 2012 at 11:52 AM, Satoshi Nagayasu wrote:
> > I agree with that such performance instrument needs to be
> > improved if it has critical performance issue against
> > production environment. So, I'm still looking for a better
> > implementation to decrease pe
On Sat, Oct 20, 2012 at 1:03 AM, Satoshi Nagayasu wrote:
> 2012/10/19 23:48, Fujii Masao wrote:
>>
>> On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu
>> wrote:
>>>
>>> 2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
>
>
> Satoshi
2012/10/20 2:45, Tom Lane wrote:
> Satoshi Nagayasu 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
On Fri, Oct 19, 2012 at 11:52 AM, Satoshi Nagayasu wrote:
> I agree with that such performance instrument needs to be
> improved if it has critical performance issue against
> production environment. So, I'm still looking for a better
> implementation to decrease performance impact.
Frankly, I th
Satoshi Nagayasu 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
2012/10/19 23:48, Fujii Masao wrote:
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu wrote:
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
The tracing lwlock usage seems to still ca
2012/10/19 4:36, Robert Haas wrote:
On Tue, Oct 16, 2012 at 11:31 AM, Satoshi Nagayasu wrote:
A flight-recorder must not be disabled. Collecting
performance data must be top priority for DBA.
This analogy is inapposite, though, because a flight recorder rarely
crashes the aircraft. If it did
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu wrote:
> 2012/10/16 2:40, Jeff Janes wrote:
>>
>> On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
>>>
>>> Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
>
> The tracing lwlock usage seems to still cause a smal
On Thu, Oct 18, 2012 at 10:36 PM, Robert Haas wrote:
> Sadly, the situation on Windows doesn't look so good. I
> don't remember the exact numbers but I think it was something like 40
> or 60 or 80 times slower on the Windows box one of my colleagues
> tested than it is on Linux.
Do you happen to
On Tue, Oct 16, 2012 at 11:31 AM, Satoshi Nagayasu wrote:
> A flight-recorder must not be disabled. Collecting
> performance data must be top priority for DBA.
This analogy is inapposite, though, because a flight recorder rarely
crashes the aircraft. If it did, people might have second thoughts
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
The tracing lwlock usage seems to still cause a small performance
overhead even if reporting is disabled. I believe some users would
prefer to a
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> (2012/10/14 13:26), Fujii Masao wrote:
>>> The tracing lwlock usage seems to still cause a small performance
>>> overhead even if reporting is disabled. I believe some users would
>>> prefer to avoid such overhead even
2012/10/15 1:43, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> (2012/10/14 13:26), Fujii Masao wrote:
>>> The tracing lwlock usage seems to still cause a small performance
>>> overhead even if reporting is disabled. I believe some users would
>>> prefer to avoid such overhead even if pg_stat_lwloc
Satoshi Nagayasu writes:
> (2012/10/14 13:26), Fujii Masao wrote:
>> The tracing lwlock usage seems to still cause a small performance
>> overhead even if reporting is disabled. I believe some users would
>> prefer to avoid such overhead even if pg_stat_lwlocks is not available.
>> It should be up
On Sun, Oct 14, 2012 at 7:52 PM, Satoshi Nagayasu wrote:
> (2012/10/14 13:26), Fujii Masao wrote:
>>
>> On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu
>> wrote:
>>>
>>> HEAD
>>>
>>> number of transactions actually processed: 3439971
>>> tps = 57331.891602 (including connections establish
(2012/10/14 13:26), Fujii Masao wrote:
On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu wrote:
HEAD
number of transactions actually processed: 3439971
tps = 57331.891602 (including connections establishing)
tps = 57340.932324 (excluding connections establishing)
pg_stat_lwlocks patch
On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu wrote:
> HEAD
>
> number of transactions actually processed: 3439971
> tps = 57331.891602 (including connections establishing)
> tps = 57340.932324 (excluding connections establishing)
> pg_stat_lwlocks patch (reporting disabled)
> =
Thanks for the review.
2012/10/14 8:55, Michael Paquier wrote:
On Sun, Oct 14, 2012 at 6:00 AM, Fujii Masao mailto:masao.fu...@gmail.com>> wrote:
On Sun, Oct 14, 2012 at 3:34 AM, Fujii Masao mailto:masao.fu...@gmail.com>> wrote:
> On Sat, Oct 13, 2012 at 11:34 PM, Satoshi Nagayasu
On Sun, Oct 14, 2012 at 6:00 AM, Fujii Masao wrote:
> On Sun, Oct 14, 2012 at 3:34 AM, Fujii Masao
> wrote:
> > On Sat, Oct 13, 2012 at 11:34 PM, Satoshi Nagayasu
> wrote:
> >> Hi,
> >>
> >> 2012/10/13 23:05, Satoshi Nagayasu wrote:
> >>> Hi all,
> >>>
> >>> I have fixed my previous patch for p
On Sun, Oct 14, 2012 at 3:34 AM, Fujii Masao wrote:
> On Sat, Oct 13, 2012 at 11:34 PM, Satoshi Nagayasu wrote:
>> Hi,
>>
>> 2012/10/13 23:05, Satoshi Nagayasu wrote:
>>> Hi all,
>>>
>>> I have fixed my previous patch for pg_stat_lwlocks view, and
>>> as Josh commented, it now supports local and
On Sat, Oct 13, 2012 at 11:34 PM, Satoshi Nagayasu wrote:
> Hi,
>
> 2012/10/13 23:05, Satoshi Nagayasu wrote:
>> Hi all,
>>
>> I have fixed my previous patch for pg_stat_lwlocks view, and
>> as Josh commented, it now supports local and global (shared)
>> statistics in the same system view.
>
> Sor
Hi,
2012/10/13 23:05, Satoshi Nagayasu wrote:
> Hi all,
>
> I have fixed my previous patch for pg_stat_lwlocks view, and
> as Josh commented, it now supports local and global (shared)
> statistics in the same system view.
Sorry, I found my mistakes. New fixed one is attached to this mail.
Regar
Hi all,
I have fixed my previous patch for pg_stat_lwlocks view, and
as Josh commented, it now supports local and global (shared)
statistics in the same system view.
Local statistics means the counters are only effective in the
same session, and shared ones means the counters are shared within
th
> To implement it, a new array can be added in the local process memory
> to hold lwlock statistics, and update counters both in the shared
> memory and the local process memory at once. Then, the session can
> retrieve 'per-session' statistics from the local process memory
> via some dedicated fu
Hi all,
I've modified the pg_stat_lwlocks patch to be able to work with
the latest PostgreSQL Git code.
This patch provides:
pg_stat_lwlocks New system view to show lwlock statistics.
pg_stat_get_lwlocks() New function to retrieve lwlock statistics.
pg_stat_reset_lwlocks() N
2012/06/26 7:04, Kevin Grittner wrote:
Josh Berkus wrote:
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the
patch, and confirmed that this patch does not affect the LWLock
perfomance at all.
This would be my main
2012/06/26 6:44, Josh Berkus wrote:
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the patch,
and confirmed that this patch does not affect the LWLock perfomance
at all.
This would be my main concern with this patch;
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
> (1) Performance
>
> I've measured LWLock performance both with and without the patch,
> and confirmed that this patch does not affect the LWLock perfomance
> at all.
This would be my main concern with this patch; it's hard for me to
imagine that
Hi all,
I've been working on a new system view, pg_stat_lwlocks, to observe
LWLock, and just completed my 'proof-of-concept' code that can work
with version 9.1.
Now, I'd like to know the possibility of this feature for future
release.
With this patch, DBA can easily determine a bottleneck aroun
30 matches
Mail list logo
