Re: RFC: list API / memory allocations
От | Robert Haas |
---|---|
Тема | Re: RFC: list API / memory allocations |
Дата | |
Msg-id | CA+Tgmobvntya5fOg2cHKypxLRLinOB00Ks5FEvL4=bxJ52HN_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: list API / memory allocations (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
On Sat, Nov 19, 2011 at 12:33 PM, Stephen Frost <sfrost@snowman.net> wrote: > You've mentioned that before and, to be honest, I could have sworn that > we're doing that already.. I tried to write a patch for that at one point, but it crashed and burned over the exact same set of issues discussed upthread, which I wasn't able to resolve satisfactorily. It's just really difficult to change the API for something like memory allocation after the fact; it's too hard to find the bits of code that do whatever naughty thing you don't want them to. One random idea... would there by any sense in having a palloc-like function that is defined to allocate multiple objects at once? In other words, if you need 4 list cells, then instead of asking palloc for them one at a time, you make one function call and get four pointers back at one go. I'm not sure whether that would help at all; palloc might not be able to take advantage of the additional information usefully. To some extent I feel like this is all optimizing something that's likely already so well-optimized that future gains, if any, are likely to be small. I feel like the only way we're likely to get much of a win here is if we can reduce the amount of memory that has to be allocated in the first place (allocate fewer data structures, don't copy them as much, etc.). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: