I am trying to understand how memory is allocated/used by our Postgresql 
Database connections.  From reading the documentation it appears that work_mem 
and temp_buffers are the 2 largest contributors (and work_mem usage can grow) 
to the memory utilized by the Database connections.  In addition, if I 
understand correctly, work_mem and temp_buffers each have their own pool, and 
thus database connections use (when needed) and return memory to these pools.  
I have not read this anywhere, but based on observation it appears that once 
these pools grow, they never release any of the memory (e.g. they do not shrink 
in size if some of the memory has not been for a given period of time).

With that said, are there any mechanisms available to determine how much 
work_mem and temp_buffers memory has been allocated by the Postgres database 
(and by database connection/process would be very useful as well)?  Also, which 
postgres process manages the memory pools for work_mem and temp_buffers?

FYI – I am using smem (on a linux server) to monitor the memory allocated to 
our Database connections.  In an attempt to lower our memory footprint, I 
lowered our setting for work_mem from 1MB down to 500kB (in addition I enabled 
log_temp_files to see the SQL statements that now use temp files for sorting 
and hash operations).  As I expected the memory used by the connections that 
were doing large sorts went down in size.  However, one of those DB connections 
dramatically increased in memory usage with this change.  It went from approx. 
6MB up to 37MB in memory usage?  Are temp_buffers used in conjunction with some 
sorting operations that use temp_files (and thus this connection allocated 
several temp_buffers?  Although I thought the temp_buffers parameter was the 
amount of memory that would be allocated for a session (e.g. there is no 
multiplying factor like the work_mem for a session)?

We are using Postgres 9.0.13
  shared_buffers = 800MB
  work_mem = 1MB
  temp_buffers = 8MB   (our applications do not use temp tables)
  effective_cache_size = 1500MB

Thanks,
Alan

Reply via email to