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

Re: What is wrong with hashed index usage?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Loftis <mloftis(at)wgops(dot)com>
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:14:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 MomjianDate: 2002-04-25 21:25:47
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Neil ConwayDate: 2002-04-25 21:04:44
Subject: Re: What is wrong with hashed index usage?

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