2010/3/11 Alvaro Herrera <alvhe...@commandprompt.com>: > Pavel Stehule escribió: >> 2010/3/11 Tom Lane <t...@sss.pgh.pa.us>: >> > Pavel Stehule <pavel.steh...@gmail.com> writes: >> >> The problem is in very large small allocations - there are 853215 nodes. >> >> I replaced palloc0 inside mkSPnode by balloc >> > >> > This goes back to the idea we've discussed from time to time of having a >> > variant memory context type in which pfree() is a no-op and we dispense >> > with all the per-chunk overhead. I guess that if there really isn't any >> > overhead there then pfree/repalloc would actually crash :-( but for the >> > particular case of dictionaries that would probably be OK because >> > there's so little code that touches them. >> >> it has a sense. I was surprised how much memory is necessary :(. Some >> smarter allocation save 50% - 2.5G for 100 users, what is important, >> but I thing, so these data has to be shared. I believed to preloading, >> but it is problematic - there are no data in shared preload time, and >> the allocated size is too big. > > Could it be mmapped and shared that way?
I don't know - I newer worked with mmap. Pavel > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > The PostgreSQL Company - Command Prompt, Inc. > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
