Re: Profiling custom datatypes - Mailing list pgsql-general

From Tom Lane
Subject Re: Profiling custom datatypes
Date
Msg-id 5615.1238007186@sss.pgh.pa.us
Whole thread Raw
In response to Profiling custom datatypes  (William Harrower <wjh105@doc.ic.ac.uk>)
List pgsql-general
William Harrower <wjh105@doc.ic.ac.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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.3.7 Windows Update Error
Next
From: "Daniel Verite"
Date:
Subject: Re: text column constraint, newbie question