Profiling custom datatypes

Поиск
Список
Период
Сортировка
От William Harrower
Тема Profiling custom datatypes
Дата
Msg-id 49CA67F5.9070408@doc.ic.ac.uk
обсуждение исходный текст
Ответы Re: Profiling custom datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Richard Broersma
Дата:
Сообщение: 8.3.7 Windows Update Error
Следующее
От: Peter Willis
Дата:
Сообщение: Re: Proper entry of polygon type data