Profiling custom datatypes - Mailing list pgsql-general

From William Harrower
Subject Profiling custom datatypes
Date
Msg-id 49CA67F5.9070408@doc.ic.ac.uk
Whole thread Raw
Responses Re: Profiling custom datatypes
List pgsql-general
Hi,

I'm attempting to profile (the memory usage and CPU time of) some code
I've written as part of a custom datatype. I've attempted to utilise
valgrind and cachegrind, but this doesn't seem to work as expected. The
following is the command used:

valgrind --tool=cachegrind --trace-children=yes ./postgres -D ../data

Running this and then invoking a SQL query that causes my code to
execute doesn't seem to result in any output relating to my datatype,
even though its code is taking the majority of the CPU time.

Does anyone know what I'm doing wrong -- do I have to do something
special for valgrind to inspect shared libraries? I have debug symbols
compiled in everywhere.

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? 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.

Many thanks for any help,
Will.

pgsql-general by date:

Previous
From: Richard Broersma
Date:
Subject: 8.3.7 Windows Update Error
Next
From: Peter Willis
Date:
Subject: Re: Proper entry of polygon type data