Tom Lane wrote:
> For the record, I think this patch is a waste of manpower and we should
> rely on dtrace/systemtap. However, if we are going to make our own
> homegrown substitute for those facilities, a minimum requirement should
> be that it uses the dtrace macros already put into the sourc
On Tue, Jul 21, 2009 at 10:36 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Well, the objection remains: We already have dtrace support, and dtrace or
>> dtrace-like systems are spreading to many operating systems, so one wonders
>> whether it is useful to clutter the code with another probing
Hi,
Tom Lane writes:
> For the record, I think this patch is a waste of manpower and we should
> rely on dtrace/systemtap. However, if we are going to make our own
> homegrown substitute for those facilities, a minimum requirement should
> be that it uses the dtrace macros already put into the s
Peter Eisentraut writes:
> Well, the objection remains: We already have dtrace support, and dtrace or
> dtrace-like systems are spreading to many operating systems, so one wonders
> whether it is useful to clutter the code with another probing system instead
> of putting some resources, say, in
On Tuesday 21 July 2009 09:09:54 Dimitri Fontaine wrote:
> > * Is it ok we have two versions of profiling? (this and dtrace
> > probes)
>
> Can't comment on this, never used dtrace before, don't have a version
> of it on my production systems.
Well, the objection remains: We already have dtra
Hi,
Le 21 juil. 09 à 07:57, Itagaki Takahiro a écrit :
Oops, I must fix it. I didn't test well the default stack depth (10).
I'd better not have limitation of condition stack.
I'm glad to hear it's possible to implement without arbitrary limits :)
BTW, I hope I have enough feedbacks from rev
Dimitri Fontaine wrote:
> WARNING: condition stack overflow: 10
> So I'm going to change patch state to "Returned with Feedback" as I
> guess we'll need to talk about the issue and find a way to solve it,
> and I don't think this state prevent from getting back to the patch in
> this same
On Sun, Jul 19, 2009 at 8:53 AM, Dimitri Fontaine wrote:
> Oh and I see that "Returned with feedback" did set a "Close Date", so it's
> not what I intended anyway. I've changed the status to "Waiting on Author"
> and if we have no news before the end of current commit fest, I'll then move
> it to "
Hi,
Le 19 juil. 09 à 06:30, Robert Haas a écrit :
On Sat, Jul 18, 2009 at 5:28 PM, Tom Lane wrote:
What do you want to use then ... Waiting on Author?
Yeah, that's what I was thinking.
Oh and I see that "Returned with feedback" did set a "Close Date", so
it's not what I intended anyway. I
On Sat, Jul 18, 2009 at 5:36 PM, Jaime
Casanova wrote:
> On Sat, Jul 18, 2009 at 3:38 PM, Robert Haas wrote:
>> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
>> wrote:
>>> So I'm going to change patch state to "Returned with Feedback" as I guess
>>> we'll need to talk about the issue and find
On Sat, Jul 18, 2009 at 5:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
>> wrote:
>>> So I'm going to change patch state to "Returned with Feedback" as I guess
>>> we'll need to talk about the issue and find a way to solve it, and I don't
>>> th
On Sat, Jul 18, 2009 at 3:38 PM, Robert Haas wrote:
> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
> wrote:
>> So I'm going to change patch state to "Returned with Feedback" as I guess
>> we'll need to talk about the issue and find a way to solve it, and I don't
>> think this state prevent fr
Robert Haas writes:
> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine
> wrote:
>> So I'm going to change patch state to "Returned with Feedback" as I guess
>> we'll need to talk about the issue and find a way to solve it, and I don't
>> think this state prevent from getting back to the patch in
On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine wrote:
> So I'm going to change patch state to "Returned with Feedback" as I guess
> we'll need to talk about the issue and find a way to solve it, and I don't
> think this state prevent from getting back to the patch in this same fest.
In general
Hi,
Le 14 juil. 09 à 11:47, Itagaki Takahiro a écrit :
I updated Sampling profiler patch to be applied to HEAD cleanly.
Which I confirm, as I just spent some time to reviewing the patch (it
was left unassigned in the commit fest). Reviewing code didn't strike
anything so obvious that I'd n
Hi!
Thanks for your answer. Here is my general reasoning: I was thinking
about a way to use the profiler to determine the resource profile even
of (maybe even short time) business transactions. I would like to leave
the technical focus (high CPU usage, high I/O rate, too many disk sorts,
...) to
Stefan Moeding wrote:
> Have you thought about keeping the counters for each backend isolated?
> I think in the end it would be beneficial to be able to break down the
> response time for a critical business transaction in isolation instead
> of having all backends in one figure.
I think per-ba
Hi!
Itagaki Takahiro writes:
> I updated Sampling profiler patch to be applied to HEAD cleanly.
>
> [...]
>
> Comments welcome.
I believe the profiler could give us a better understanding of where
different parts of the user visible response time originate from. The
problem with DTrace in my op
On Tue, Jul 14, 2009 at 4:47 AM, Itagaki
Takahiro wrote:
> I updated Sampling profiler patch to be applied to HEAD cleanly.
>
shouldn't pg_stat_reset() reset these values?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
C
I updated Sampling profiler patch to be applied to HEAD cleanly.
Basic concept of the patch is same as DTrace probes:
Call pgstat_push_condition(condition) before a operation and call
pgstat_pop_condition() at the end of the operation. Those functions
should be light-weight because they only chang
20 matches
Mail list logo
