On Fri, Jul 18, 2008 at 10:44 AM, Heikki Linnakangas
<heikki@enterprisedb.com> wrote:
> Ignoring the big-O complexity, if a hash index only stores a 32-bit hash
> code instead of the whole key, it could be a big win in storage size, and
> therefore in cache-efficiency and performance, when the keys are very long.
Agreed. My thinking is that there's either something inherently wrong
with the implementation, or we're performing so many disk I/Os that
it's nearly equivalent to b-tree. Tom has a couple suggestions which
Xiao and I will explore.
> Granted, it's not very common to use a 1K text field as a key column...
Especially for direct equality comparison :)
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/
