> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Simon Riggs
> Sent: Tuesday, May 19, 2009 4:32 AM
> To: pgsql-hackers
> Subject: [HACKERS] Multiple sorts in a query
>
>
> Just wanted to check some thoughts about how memory allocation works in
> complex queries. Been thinking some more about recent Solaris testing
> results that *seemed* to show issues with multiple concurrent queries
> that have multiple sorts.
>
> If we have a query that uses multiple sorts, we may have a top-level
> sort, with child nodes that contain sorts also. In some cases we may
> find with sub-nodes that have both inner and outer sub-trees that
> contain sorts also.
>
> If we allocate large chunks of memory we use malloc(). So complex
> queries can have multiple mallocs, followed by multiple reallocs. That
> in itself seems likely to end up with roughly double memory use, since
> realloc won't work properly/quickly with multiple mallocs. (Double
> since
> we allocate X bytes, then 2X bytes etc until we hit the limit.)
>
> When we later free() the memory, do we always free() it in the reverse
> order in which it was allocated? If not, how does that effect reducing
> the sbrk point, or other aspects of reusing allocated memory?
>
> Is it possible that Solaris's default malloc isn't appropriate for
> repeated use in complex queries that use multiple sorts?
> http://developers.sun.com/solaris/articles/multiproc/multiproc.html
> and recent OpenSolaris bug reports.
Solaris default malloc always uses sbrk(), and never ever tried to reduce the sbrk point.
If you want a malloc that uses mmap, there is an non-default malloc that does that (libumem or something?)
