Re: Profiling custom datatypes

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

In response to

Browse pgsql-general by date

  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