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 reviewers if the patch is
"Returned with Feedback". Are there any issues I need to fix or
improve
by the next commitfest?
I feel we don't have enough discussion about the feature, like:
* Is is useful enough? or are there any idea to be more useful?
It looks very useful but I didn't have time to play around enough with
it (stopped at warnings, which were very early in testing). It seems
not possible to reset the profiles then launch a query and see stats
for only this query run? (all backends will be profiled together).
Knowing what sort of workload (very detailed here, which is good) is
running is good though, I think I'm going to use it when available :)
* 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.
* Is the quality of the patch enough in terms of implmentation?
I've raised some questions related on performance impact of function
calls when profiling is disabled and the code changes related to how
to take some locks, I didn't have more comments than that (didn't spot
other comments to get done).
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
