ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I assume we want to gather the statistics per resource (represented by
> LWLockKind in my patch), not per LWLockId.
Why? I haven't yet seen any problem where that looked useful.
The named LWLocks are certainly sui generis, and as for things like
per-
Robert Lor <[EMAIL PROTECTED]> wrote:
> CVS head now has the following LWLock probes, and more can easily be
> added. These probes can be enabled using the sample DTrace scripts at
> http://pgfoundry.org/projects/dtrace/
>
> lwlock-acquire
> lwlock-release
> lwlock-startwait
> lwlock-endwait
>
Tom Lane wrote:
I think the actual wave of the future for analyzing behavior at the
LWLock level is going to be DTrace. It seems way more flexible than
an aggregate-statistics view can be.
CVS head now has the following LWLock probes, and more can easily be
added. These probes can be enable
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> This seems fairly invasive, as well as confused about whether it's an
>> #ifdef'able thing or not. You can't have system views and pg_proc
>> entries conditional on a compile-time #ifdef, so in a default build
>>
Tom Lane wrote:
> I'm confused ... is this patch being proposed for inclusion? I
> understood your previous message to say that it didn't help much.
This is only the patch for carving where there is any problem.
> The patch is buggy as posted, because it will try to do this:
> if (s
Tom Lane <[EMAIL PROTECTED]> wrote:
> This seems fairly invasive, as well as confused about whether it's an
> #ifdef'able thing or not. You can't have system views and pg_proc
> entries conditional on a compile-time #ifdef, so in a default build
> we would have a lot of nonfunctional cruft expose
Katsuhiko Okano <[EMAIL PROTECTED]> writes:
>> (A) The algorithm which replaces a buffer is bad.
>> A time stamp does not become new until swapout completes
>> the swapout page.
>> If access is during swap at other pages, the swapout page will be
>> in the state where it is not used most,
>> It i
Katsuhiko Okano wrote:
> Since the cause was found and the provisional patch was made
> and solved about the CSStorm problem in previous mails, it reports.
(snip)
> (A) The algorithm which replaces a buffer is bad.
> A time stamp does not become new until swapout completes
> the swapout page.
> I
Hi,All.
Since the cause was found and the provisional patch was made
and solved about the CSStorm problem in previous mails, it reports.
> Subject: [HACKERS] poor performance with Context Switch Storm at TPC-W.
> Date: Tue, 11 Jul 2006 20:09:24 +0900
> From: Katsuhiko Okano <[EMAIL PROTECTED]>
>
