From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Neil Conway <neilc(at)samurai(dot)com>, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Christopher Petrilli <petrilli(at)gmail(dot)com>, Ying Lu <ying_lu(at)cs(dot)concordia(dot)ca>, pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
Date: | 2005-05-10 17:35:59 |
Message-ID: | 87wtq7q8zk.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > What if the hash index stored *only* the hash code? That could be useful for
> > indexing large datatypes that would otherwise create large indexes.
>
> Hmm, that could be a thought.
Hm, if you go this route of having hash indexes store tuples ordered by hash
code and storing the hash code in the index, then it seems hash indexes become
just a macro for a btree index of HASH(index columns).
I'm not saying that to criticize this plan. In fact I think that captures most
(though not all) of what a hash index should be.
It would be pretty useful. In fact if it isn't how hash indexes are
implemented then it might be useful to provide a user visible hash(ROW)
function that allows creating such indexes as functional indexes. Though
hiding it would make the SQL simpler.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-10 18:07:00 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
Previous Message | Jim C. Nasby | 2005-05-10 17:26:52 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-05-10 17:46:24 | Re: Partitioning / Clustering |
Previous Message | PFC | 2005-05-10 17:29:59 | Re: Partitioning / Clustering |