On Fri, Jul 18, 2008 at 10:44 AM, Heikki Linnakangas <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
