The idea behind hte bitmap (correct me if I'm wrong) is that when larger
allocationsa re asked for they can be quickly found and there is no need
to maintain the coalescing of smaller adjacent blocks into larger ones.
I don't know if pg does this or not, but thats the only sane reason I
can come up with.
*quietly installs an rm -rf trigger if tom does any I/O on the has files
outside of the compiler* This is for your own safety Tom... Well that
and our amusement.... :)
Tom Lane wrote:
>Michael Loftis <mloftis@wgops.com> writes:
>
>> I don't know about PGs implementation but since I assume oyu all
>>inhereted atleast part of it from the berkely boys you should be in very
>>solid form.
>>
>
>One would have thought so, wouldn't one? AFAIK the hash index code is
>lock-stock-and-barrel straight from Berkeley; we've not touched it
>except for minor tweaking (portability issues and such).
>
>I spent a little time reading the code whilst I was waiting for the hash
>index build to complete, and was kind of wondering why it bothers to
>maintain bitmaps of free space. Seems like it could just keep all the
>free pages chained together in a list, for zero overhead cost, and skip
>the bitmaps. It locks the metapage anyway when allocating or freeing
>a page, so keeping the freelist head pointer there doesn't seem like it
>would have any performance penalty...
>
><<whacks self on head>> NO <<whack>> I am not getting involved with the
>hash index code. I don't think it's worth our trouble.
>
> regards, tom lane
>