Re: Very long times to build hash indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David Monarchi" <david(dot)e(dot)monarchi(at)gmail(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Very long times to build hash indexes
Date: 2007-03-20 18:22:03
Message-ID: 15977.1174414923@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

"David Monarchi" <david(dot)e(dot)monarchi(at)gmail(dot)com> writes:
> We need to build indexes on 10 foreign key fields in the core table. Based
> on the type of queries and the fact that insertions in it are fast, we are
> building hash indexes on those fields. We have successfully built 5 of the
> 10 hash indexes. Each one required about 20 hours to construct.

> When we got to the 6th field, we found that the indexing process would not
> terminate even after 70 hours. We then tried the 7th field with the same
> result. Is there something that we've overlooked?

The short answer is that Postgres' hash indexes suck. The degree of
suckiness varies by PG version (which you failed to mention) but there
is no release currently in which I would use them in preference to a
btree index. The lack of WAL support is alone a sufficient reason why
they're unacceptable for production use, but on top of that they don't
actually have any performance advantage in any tests that I've seen.

regards, tom lane

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Phillip Smith 2007-03-21 04:29:17 Re: Formating Date Data Type?
Previous Message David Monarchi 2007-03-20 17:51:48 Very long times to build hash indexes