Thread: How exactly PostgreSQL allocates memory for its needs?

Can anybody briefly explain me how each postgres process allocate
memory for it needs?
I mean, what is the biggest size of malloc() it may want? How many
such chunks? What is the average size of allocations?

I think that at first it allocates contiguous piece of shared memory
for "shared buffers" (rather big, hundreds of megabytes usually, by
one chunk).
What next? temp_buffers, work_mem, maintenance_work_mem - are they
allocated as contiguous too?
What about other needs? By what size they are typically allocated?
--
antonvm

On 2/10/2010 12:10 AM, Anton Maksimenkov wrote:
> Can anybody briefly explain me how each postgres process allocate
> memory for it needs?
> I mean, what is the biggest size of malloc() it may want? How many
> such chunks? What is the average size of allocations?
>
> I think that at first it allocates contiguous piece of shared memory
> for "shared buffers" (rather big, hundreds of megabytes usually, by
> one chunk).
> What next? temp_buffers, work_mem, maintenance_work_mem - are they
> allocated as contiguous too?
> What about other needs? By what size they are typically allocated?
>

There  is no short answer to this, you should read section 18 of the manual
http://www.postgresql.org/docs/8.4/interactive/runtime-config.html
specifically section 18.4
http://www.postgresql.org/docs/8.4/interactive/runtime-config-resource.html

and performance section of the wiki
http://wiki.postgresql.org/wiki/Performance_Optimization

Here is a link annotated postgresql.conf
http://www.pgcon.org/2008/schedule/attachments/44_annotated_gucs_draft1.pdf

Keep in mind each connection/client that connecting to the server
creates a new process on the server.  Each one the settings you list
above is the max amount of memory each one of those sessions is allowed
to consume.



All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by
ourproprietary quotation system. Quotations received via any other form of communication will not be honored. 

CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other
informationproprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it
addresses.If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified
thatany unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have
receivedthis e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this
e-mailimmediately. 
Thank you.

On Wed, Feb 10, 2010 at 9:43 AM, Justin Graf <justin@magwerks.com> wrote:
> Keep in mind each connection/client that connecting to the server
> creates a new process on the server.  Each one the settings you list
> above is the max amount of memory each one of those sessions is allowed
> to consume.

It's even worse for work_mem (formerly sort_mem) in that each
individual hash agg or sort can grab that much memory.  A complex
query with 4 sorts and 2 hash aggregates could chew through 6 x
work_mem if it needed it.  Which is why work_mem can be such a
horrific foot gun.