Profiling custom datatypes

From: William Harrower <wjh105(at)doc(dot)ic(dot)ac(dot)uk>
To: pgsql-general(at)postgresql(dot)org
Subject: Profiling custom datatypes
Date: 2009-03-25 17:20:53
Message-ID: 49CA67F5.9070408@doc.ic.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Duffey 2009-03-25 17:22:51 could not access status of transaction
Previous Message Merlin Moncure 2009-03-25 16:50:01 Re: MAX(ROW(...)) - feature request