Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?
Дата
в 17:02:55
Msg-id
4272.1304366554@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Merlin Moncure <mmoncure@gmail.com>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Merlin Moncure <mmoncure@gmail.com>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Merlin Moncure <mmoncure@gmail.com>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Merlin Moncure <mmoncure@gmail.com>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Merlin Moncure <mmoncure@gmail.com>
Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? Tom Lane <tgl@sss.pgh.pa.us>
Merlin Moncure  writes:
> On Mon, May 2, 2011 at 11:09 AM, Tom Lane  wrote:
>> I did a bit of testing of this and committed it with minor adjustments.

> Thanks for the attribution -- I hardly deserved it.  One question
> though: ALLOC_CHUNK_FRACTION was put to four with the language 'We
> allow chunks to be at most 1/4 of maxBlockSize'.

> further down we have:
> "+    * too.  For the typical case of maxBlockSize a power of 2, the chunk size
> +    * limit will be at most 1/8th maxBlockSize, so that given a stream of
> +    * requests that are all the maximum chunk size we will waste at most
> +    * 1/8th of the allocated space."

> Is this because the divide by 2 right shift halves the amount of
> wasted space, so that the maximum waste is in fact half again the
> fraction?

No, it's the overhead.  The patch as you submitted it was forcing
allocChunkSize down to 512, because after subtracting off the
per-malloc-block overhead and the per-palloc-chunk overhead, it came to
the (correct) conclusion that 1024 didn't quite fit 8 times into 8192.
I thought that was probably excessive, so I backed off the fraction.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Alvaro Herrera
Дата:
Сообщение: Re: HTML tags :/
От: David Fetter
Дата:
Сообщение: Re: HTML tags :/
FAQ