Skip site navigation (1) Skip section navigation (2)

Re: PL/pgSQL memory consumption?

From: "Dawid Kuroczko" <qnex42(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PL/pgSQL memory consumption?
Date: 2008-02-25 00:49:33
Message-ID: 758d5e7f0802241649t2e223675n3e59254c300d9cae@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Fri, Feb 22, 2008 at 3:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrot>
"Dawid Kuroczko" <qnex42(at)gmail(dot)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.

In response to

pgsql-admin by date

Next:From: Dawid KuroczkoDate: 2008-02-25 01:02:17
Subject: Re: WAL archiving
Previous:From: Shilpa SudhakarDate: 2008-02-24 23:24:34
Subject: Re: WAL archiving

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group