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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
