Re: What is wrong with hashed index usage?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, mloftis(at)wgops(dot)com, DCorbit(at)connx(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: What is wrong with hashed index usage?
Date: 2002-04-26 02:32:14
Message-ID: 20276.1019788334@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I hate to do that because it makes people think something special is
> happening for hash, but it isn't. We could throw an elog(NOTICE)
> stating that hash is not recommended and btree is faster, or something
> like that.

I think the only action called for is some improvement in the
documentation. Right now the docs are not honest about the state
of any of the non-btree index methods. Ain't none of 'em ready
for prime time IMHO. GIST is the only one that's getting any
development attention --- and probably the only one that deserves
it, given limited resources. Hash offers no compelling advantage
over btree AFAICS, and rtree is likewise dominated by GIST (or would
be, if we shipped rtree-equivalent GIST opclasses in the standard
distribution).

I do not like "throw an elog" as a substitute for documentation.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2002-04-26 02:37:08 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Rod Taylor 2002-04-26 02:30:45 pg_constraint