On Fri, Dec 18, 2015 at 10:12 AM, Robert Haas <robertmh...@gmail.com> wrote: > I don't really like the term "memory pool" either. We're growing a > bunch of little special-purpose allocators all over the code base > because of palloc's somewhat dubious performance and memory usage > characteristics, but if any of those are referred to as memory pools > it has thus far escaped my notice.
BTW, I'm not necessarily determined to make the new special-purpose allocator work exactly as proposed. It seemed useful to prioritize simplicity, and currently so there is one big "huge palloc()" with which we blow our memory budget, and that's it. However, I could probably be more clever about "freeing ranges" initially preserved for a now-exhausted tape. That kind of thing. With the on-the-fly merge memory patch, I'm improving locality of access (for each "tuple proper"/"tuple itself"). If I also happen to improve the situation around palloc() fragmentation at the same time, then so much the better, but that's clearly secondary. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
