Re: [HACKERS] LWLock statistics collector

2006-08-06 Thread ITAGAKI Takahiro
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

Re: [HACKERS] LWLock statistics collector

2006-08-04 Thread ITAGAKI Takahiro
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 exposed to

Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-08-04 Thread Katsuhiko Okano
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

Re: [HACKERS] LWLock statistics collector

2006-08-04 Thread Tom Lane
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 we would

Re: [HACKERS] LWLock statistics collector

2006-08-04 Thread Robert Lor
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

Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-08-03 Thread Tom Lane
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 is again

Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-07-31 Thread Katsuhiko Okano
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]

Re: [HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-07-31 Thread Katsuhiko Okano
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. If

[HACKERS] LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

2006-07-28 Thread ITAGAKI Takahiro
Hi hackers, I tackled the performance problem on SUBTRANS module with Okano. He and I reach a conclusion that SubTrans log is heavily read on a specific access pattern in my TPC-W implementation. There seems to be awful traffic on SUBTRANS to check visivility of tuples in