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.
Anyway, feel free to jump in.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
