Re: Postgres Connections Requiring Large Amounts of Memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dawn Hollingsworth <dmh(at)airdefense(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres Connections Requiring Large Amounts of Memory
Date: 2003-06-16 21:34:29
Message-ID: 6892.1055799269@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Dawn Hollingsworth <dmh(at)airdefense(dot)net> writes:
> There are two things which might be considered off the beaten path
> though:
> 1. We have tables that have over 500 columns which we continually insert
> into and select from.
> 2. Our stored procedures take more than 16 parameters so in the file
> config.h the value INDEX_MAX_KEYS was increased to 100.

Neither of those raises a red flag with me.

What would be useful to try to narrow things down is to look at the
output of "MemoryContextStats(TopMemoryContext)" in a backend that's
grown to a large size. This is a fairly primitive routine
unfortunately; there is no built-in way to invoke it other than by
calling it manually with a debugger, and it is only bright enough
to write to stderr, not syslog. If you have stderr going somewhere
useful (not /dev/null) and you built with debugging symbols, then you
could attach to a running backend right now with gdb and get some useful
info. If you don't have debugging symbols then you'll need to either
rebuild with 'em, or create some other way to call the function.
(There is a bit of stub code marked #ifdef SHOW_MEMORY_STATS in
postgres.c that might be worth enabling, but I think it's only a sketch
and won't compile as-is, since I don't see a ShowStats variable
anywhere.)

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jim C. Nasby 2003-06-16 22:32:09 Re: Partial index where clause not filtering through
Previous Message Tom Lane 2003-06-16 20:45:02 Re: Postgres Connections Requiring Large Amounts of Memory