-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Shreya Bhargava wrote:
> "Note that the bottom line for the problems with hash indexes is that the
> current implementation doesn't offer any advantages over btree indexes. Hash
> indexes need to be not only as good of a choice as btree indexes but
> significantly better a significantly better choice at least for some
> specific circumstances."
Oh it does. I recently used a hash index to speed up my database. Namely
I found it improved performance when indexing a non-integer column
containing english words.
I don't know how much of that data was cached, according to the sound
of my harddrive it wasn't all of it. Consider this anecdotical
evidence, but the speedup was noticeable.
> We performed some probe tests on our patch on
> hash index and the original btree index to compare the
> performance between the two. We used a 80 million tuple table.
> The table contained single integer attribute and the data
> range was 0 - 100000000. (generated by a random generator).
I'd be interested how much difference is there between non-integer
index behaviour. I at least had the impression that in my case
the sorted strings in the btree pages didn't compare too well.
> */Gregory Stark <stark@enterprisedb.com>/* wrote:
> "Kenneth Marshall" writes:
> > On Thu, Sep 20, 2007 at 05:12:45PM -0700, Tom Raney wrote:
> >> Using our implementation, build times and index sizes are
> >> comparable with btree index build times and index sizes.
Way to go! Currently building hash indices is no fun.
Regards, Jens-W. Schicke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHMErXzhchXT4RR5ARAh7pAKCZIZFJFa7Oq25GvwDhiZJFsrtwgACbBC1F
otwhIZVlNgUGlroePIafi1c=
=N1f7
-----END PGP SIGNATURE-----
