Robert Haas píše v čt 10. 12. 2009 v 23:55 -0500:
> On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala <zdenek.kot...@sun.com> wrote:
> >
> > But in normal situation database does also other thing and palloc is
> > only one part of code path. It is why I run second test and use sun
> > studio profiling tools (collect/analyzer) to determine how much CPU
> > ticks cost the probes during pg_bench run. And results are much better.
> > AllocSet alloc function takes about 4-5% and probes assembler code takes
> > 0.1-0.2% on 64bit. I did not test 32bit but my expectation is that it
> > should be about 0.3-0.4%.
>
> There's not really enough detail here to determine what you tested and
> what the results were, and I don't think this patch has any chance at
> all of getting committed without that. Please clarify.
>
> If there's some real-world test where this probe costs 0.3%-0.4%, I
> think that is sufficient grounds for rejecting this patch. I
> understand the desire of people to be able to use dtrace, but our
> performance is too hard-won for me to want to give any measurable of
> it up for tracing and instrumentation hooks that will only be used by
> a small number of users in a small number of situations.
>
As I mentioned I run pg_bench -c10 -t1000 and collect data from
backends. collect and analyzer is similar tool to gprof.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
