On Fri, Feb 22, 2008 at 3:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrot>
"Dawid Kuroczko" <qnex42@gmail.com> writes:
> > I have recently found a nice utility called memstat (which shows how
> > much of private
> > (not shared)) memory each process uses. What kind of surprised me was
> > the amount
> > of memory that is used by PL/pgSQL (one more reason not to provide it
> > by default? ;-)).
I am sorry it took me so much time to respond, but was out-of-reach-of-PC
on the weekend.
> Why should we put any credence whatsoever in these numbers?
> I rather doubt that "memstat" knows anything about our palloc
> mechanism, so I don't see how it could possibly give reliable
> answers about how much memory one portion or another of Postgres
> is using.
>
> Having said that, it would be interesting to know exactly what it
> *is* measuring.
What memstat [1] is doing, is that it is loading /proc/<PID>/maps
files to determine
shared objects and private memory.
What I have nailed down was that the 40MBs worth of RAM were actually
an effect of
PERFORM set_curdict('pl_ispell');
...from within PL/pgSQL function.
...if I wrap set_curdict(...) within SQL (CREATE FUNCTION ... LANGUAGE SQL), the
allocation is rightly attributed to tsearch2.so.
Regards,
Dawid
[1]: http://packages.debian.org/etch/memstat
PS: I wonder what can I do to lower the memory used by tsearch2. I
see a few options
like transaction-level pooling by pgBouncer or writing Polish snowball stemmer.
PPS: I like this memstat utility more and more -- appears to be a
helpful little utility.