Michael Loftis <mloftis(at)wgops(dot)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
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2002-04-25 21:25:47|
|Subject: Re: Vote totals for SET in aborted transaction|
|Previous:||From: Neil Conway||Date: 2002-04-25 21:04:44|
|Subject: Re: What is wrong with hashed index usage?|