Skip site navigation (1) Skip section navigation (2)

Re: What is wrong with hashed index usage?

From: Michael Loftis <mloftis(at)wgops(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>,Dann Corbit <DCorbit(at)connx(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: What is wrong with hashed index usage?
Date: 2002-04-25 21:33:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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(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: Vince VielhaberDate: 2002-04-25 21:42:33
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: F HarvellDate: 2002-04-25 21:31:36
Subject: Re: non-standard escapes in string literals

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group