On Fri, Nov 13, 2009 at 4:41 PM, Zdenek Kotala <zdenek.kot...@sun.com> wrote: > Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300: >> Zdenek Kotala wrote: >> > Attached patch contains new dtrace probes for memory management. Main >> > purpose is to analyze memory footprint - for example how many memory >> > needs transaction, peak memory per context, when memory block is reused >> > or when it is allocate by malloc and so on. >> >> Having had to instrument these to figure out some problems, I'd give >> this patch a +1. However, the performance argument is compelling. As a >> compromise, maybe we could have a #define that needs to be turned on at >> compile time to enable these probes; so a regular dtrace-enabled build >> would not have them, but if you really needed to analyze memory >> allocations, you could recompile to turn them on. > > But point of dtrace probes is that they are here without > recompilation :(. Do we have any test which we could use for performance > penalty testing? I don't think that overhead is significant.
Don't think. Benchmark. :-) (If you can measure it at all, it's too much, at least IMHO.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers