> -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@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?) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
