From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? |
Date: | 2011-05-02 20:02:34 |
Message-ID: | 4272.1304366554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Mon, May 2, 2011 at 11:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2011-05-02 20:53:35 | Re: HTML tags :/ |
Previous Message | Alvaro Herrera | 2011-05-02 19:56:42 | Re: HTML tags :/ |