Re: tsearch profiling - czech environment - take 55MB

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: tsearch profiling - czech environment - take 55MB
Дата
Msg-id 162867791003110934r504df9a3l42197f98fa33cde5@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tsearch profiling - czech environment - take 55MB  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: tsearch profiling - czech environment - take 55MB  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
2010/3/11 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@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.

Pavel


>
>                        regards, tom lane
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tsearch profiling - czech environment - take 55MB
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [patch] build issues on Win32