Re: [HACKERS] vacuum process size
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] vacuum process size |
Дата | |
Msg-id | 3691.935526084@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] vacuum process size (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] vacuum process size
|
Список | pgsql-hackers |
>> If there's no objection, I will commit included patches to the stable >> tree (seems Tom has more aggressive idea, so I'll leave the current >> tree as it is). > No, please make the change in current as well. I was thinking about > tweaking aset.c to be smarter about releasing large chunks, but in any > case having the doubling behavior at the request point will be a big > improvement. I have just committed changes into current (but not REL6_5) to make aset.c smarter about giving back memory from large requests. Basically, for chunk sizes >= ALLOC_BIGCHUNK_LIMIT, pfree() does an actual free() and repalloc() does an actual realloc(). There is no change in behavior for smaller chunk sizes. This should cap the amount of space that can be wasted by aset.c while repalloc'ing a chunk larger and larger. For lack of a better idea I set ALLOC_BIGCHUNK_LIMIT to 64K. I don't think it'd pay to make it very small, but I don't really know whether this is a good choice or not. It would still be a good idea to fix vacuum.c to double its repalloc requests at each step, but Tatsuo was already working on that part so I won't joggle his elbow... regards, tom lane
В списке pgsql-hackers по дате отправления: