Here is an updated version of sampling profiler patch.
Now condition IDs can be discrete numbers and don't have to be
continuous. It enables us to insert some new conditions between
existing numbers if needed in the future.
I think we need more discussion about how to adjust this patch
and dtrace
I wrote:
> Peter Eisentraut writes:
>> On March 10, 2009, Tom Lane wrote:
>>> FWIW, the systemtap guys are really, really close to having a working
>>> DTrace equivalent for Linux:
>>> http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/
>> So how is this going? Is it usab
Peter Eisentraut writes:
> On March 10, 2009, Tom Lane wrote:
>> FWIW, the systemtap guys are really, really close to having a working
>> DTrace equivalent for Linux:
>> http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/
> So how is this going? Is it usable? I assume it
On March 10, 2009, Tom Lane wrote:
FWIW, the systemtap guys are really, really close to having a working
DTrace equivalent for Linux:
http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/
It's not *quite* there for our purposes
https://bugzilla.redhat.com/show_bug.cgi?id=48
"Dickson S. Guedes" wrote:
> > > 2) I couldn't find a clear way to disable it. There is one in this patch
> > > or are you planning this to future?
> >
> > Ah, I forgot sampling should be disabled when track_activities is off.
> > I'll fix it in the next patch. Also, I'd better measure overhead
Hi!
Tom Lane writes:
> I'm not at all convinced that we should be putting effort into a
> homegrown, partial substitute for DTrace.
In my opinion providing DTrace as the only means of profiling would
except a number of users from the tuning benefits. DTrace seems to rely
on specific kernel opti
Simon Riggs writes:
> On Mon, 2009-03-09 at 21:57 -0400, Tom Lane wrote:
>> I'm not at all convinced that we should be putting effort into a
>> homegrown, partial substitute for DTrace.
> I was, but I'm not anymore.
> Do you think we will be able to enable this in builds for 8.4?
The bugzilla e
On Mon, 2009-03-09 at 21:57 -0400, Tom Lane wrote:
> ITAGAKI Takahiro writes:
> > For resource-based profilers, we have DTrace probes[1] and continue to
> > extend them[2], but unfortunately DTrace only works on Solaris and limited
> > platforms.
>
> FWIW, the systemtap guys are really, really c
ITAGAKI Takahiro writes:
> For resource-based profilers, we have DTrace probes[1] and continue to
> extend them[2], but unfortunately DTrace only works on Solaris and limited
> platforms.
FWIW, the systemtap guys are really, really close to having a working
DTrace equivalent for Linux:
http://gnu
Em Ter, 2009-03-10 às 10:23 +0900, ITAGAKI Takahiro escreveu:
> Thanks for testing. Network (or communication between pgbench and postgres)
> seems to be a bottleneck on your machine.
Yes, it is a very poor machine for quicktest. I'll test other
environments tomorrow.
> > Two questions here:
> >
"Dickson S. Guedes" wrote:
> Compiled and Works fine here on Ubuntu 8.04 2.6.25.15-bd-mod #1 SMP
> PREEMPT Thu Nov 27 10:05:44 BRST 2008 i686 GNU/Linux
Thanks for testing. Network (or communication between pgbench and postgres)
seems to be a bottleneck on your machine.
> Two questions here:
>
Em Seg, 2009-03-09 às 13:55 +0900, ITAGAKI Takahiro escreveu:
> Therefore, I'd like to propose an profiler with sampling approach in 8.5.
> The attached patch is an experimental model of the profiler.
> Each backends reports its condtion in PgBackendStatus.st_condition
> and the stats collector pro
Hello,
I think we need two types of profilers: SQL-based and resource-based.
We have some SQL-based profilers like slow-query logs
(log_min_duration_statement) and contrib/pg_stat_statements in 8.4.
For resource-based profilers, we have DTrace probes[1] and continue to
extend them[2], but unfortun
13 matches
Mail list logo
