On Fri, Nov 13, 2009 at 5:20 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. > > The another idea is to have two AllocSet functions set. One without and > one with dtrace probes. And switch it by GUC flag for example. From mcxt > I create and delete context is important, rest can be taken from alloc > set probes.
I've always thought it was odd that we had a function-dispatch interface in such a performance-critical path. But if we really want to keep it around this might not be a bad thing to use it for. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
