Re: What is wrong with hashed index usage? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: What is wrong with hashed index usage?
Date
Msg-id 200206211651.g5LGprw28745@candle.pha.pa.us
Whole thread Raw
In response to Re: What is wrong with hashed index usage?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: What is wrong with hashed index usage?  (Larry Rosenman <ler@lerctr.org>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I remember three problems:  build time, index size, and concurrency
> > problems.  I was wondering about the equal key case myself, and assumed
> > hash may be a win there, but with the concurrency problems, is that even
> > possible?
>
> Sure.  Many-equal-keys are a problem for btree whether you have any
> concurrency or not.
>
> > OK, I have reworded it.  Is that better?
>
> It's better, but you've still discarded the original's explicit mention
> of concurrency problems.  Why do you want to remove information?

OK, concurrency added.  How is that?

>
> > How about an elog(NOTICE) for hash use?
>
> I don't think that's appropriate.

I was thinking of this during CREATE INDEX ... hash:

    NOTICE:  Hash index use is discouraged.  See the CREATE INDEX
    reference page for more information.

Does anyone else like/dislike that?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
Index: doc/src/sgml/indices.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v
retrieving revision 1.32
diff -c -r1.32 indices.sgml
*** doc/src/sgml/indices.sgml    21 Jun 2002 03:25:53 -0000    1.32
--- doc/src/sgml/indices.sgml    21 Jun 2002 16:50:23 -0000
***************
*** 181,189 ****
  </synopsis>
     <note>
      <para>
!      Testing has shown that hash indexes are slower than btree indexes,
!      and the size and build time for hash indexes is much worse. For
!      these reasons, hash index use is discouraged.
      </para>
     </note>
    </para>
--- 181,190 ----
  </synopsis>
     <note>
      <para>
!      Testing has shown hash indexes to be similar or slower than btree
!      indexes, and the index size and build time for hash indexes is much
!      worse. Hash indexes also suffer poor performance under high
!      concurrency. For these reasons, hash index use is discouraged.
      </para>
     </note>
    </para>
Index: doc/src/sgml/ref/create_index.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v
retrieving revision 1.32
diff -c -r1.32 create_index.sgml
*** doc/src/sgml/ref/create_index.sgml    21 Jun 2002 03:25:53 -0000    1.32
--- doc/src/sgml/ref/create_index.sgml    21 Jun 2002 16:50:23 -0000
***************
*** 330,338 ****
      the <literal>=</literal> operator.
     </para>
     <para>
!      Testing has shown that hash indexes are slower than btree indexes,
!      and the size and build time for hash indexes is much worse. For
!      these reasons, hash index use is discouraged.
     </para>

     <para>
--- 330,339 ----
      the <literal>=</literal> operator.
     </para>
     <para>
!      Testing has shown hash indexes to be similar or slower than btree
!      indexes, and the index size and build time for hash indexes is much
!      worse. Hash indexes also suffer poor performance under high
!      concurrency. For these reasons, hash index use is discouraged.
     </para>

     <para>

pgsql-hackers by date:

Previous
From: "Julian Mehnle, Linksystem Muenchen"
Date:
Subject: Re: ODBC Driver 7.02.0001 (Win32) (Unicode mode): CRLF->LF works, LF->CRLF doesn't
Next
From: Tom Lane
Date:
Subject: Re: Problems with dump /restore of views