On Fri, Dec 18, 2015 at 2:57 PM, Peter Geoghegan <p...@heroku.com> wrote: > 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.
What about the case where we think that there will be a lot of data and have a lot of work_mem available, but then the user sends us 4 rows because of some mis-estimation? > 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. I don't really understand this comment. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
