Re: Postgres Connections Requiring Large Amounts of Memory - Mailing list pgsql-performance

From Tom Lane
Subject Re: Postgres Connections Requiring Large Amounts of Memory
Date
Msg-id 6892.1055799269@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postgres Connections Requiring Large Amounts of Memory  (Dawn Hollingsworth <dmh@airdefense.net>)
Responses Re: Postgres Connections Requiring Large Amounts of Memory
List pgsql-performance
Dawn Hollingsworth <dmh@airdefense.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

pgsql-performance by date:

Previous
From: Dawn Hollingsworth
Date:
Subject: Re: Postgres Connections Requiring Large Amounts of Memory
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Partial index where clause not filtering through