From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | William Harrower <wjh105(at)doc(dot)ic(dot)ac(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Profiling custom datatypes |
Date: | 2009-03-25 18:53:06 |
Message-ID: | 5615.1238007186@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
William Harrower <wjh105(at)doc(dot)ic(dot)ac(dot)uk> writes:
> Ignoring valgrind specifically, does anyone know of any other tools that
> can be used to profile the memory usage and CPU time/load of a custom
> datatype library?
oprofile on recent Fedora (and probably other Linux distros) pretty much
"just works" for shared libraries, though it only tells you about CPU
profile not memory usage. I've never been able to get gprof to do
anything useful with shlibs, on any platform :-(
> Recent changes I made to client-side code resulted in
> an increase in the size of each instance of the type it uploads to the
> database, which, for reasons unknown, has caused the search time (using
> a custom 'match' operator) to go through the roof. My suspicions suggest
> the cache memory used isn't large enough to contain the entire table
> (though perhaps it was before the change) and because of this far more
> disk reads are necessary. Hopefully a decent profiler should be able to
> make this clear.
Surely just watching iostat or vmstat would prove or disprove that
theory. Keep in mind also that CPU profilers aren't going to tell
you much about I/O costs anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-03-25 18:57:09 | Re: 8.3.7 Windows Update Error |
Previous Message | Leonardo M. Ramé | 2009-03-25 18:52:55 | Weird encoding behavior |