From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, RAJU kumar <raju_19db(at)rediffmail(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Hash index |
Date: | 2005-08-30 23:39:13 |
Message-ID: | 20050830233913.GE77007@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, Aug 30, 2005 at 04:20:03PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > So does that mean a hash index could (theoretically) improve the
> > performance of a hash join or hash aggregation?
>
> I don't think so --- the whole point of a hash is to do your matching
> in-memory, rather than jumping all over the disk for it ...
True, but if you have an index on the value you're hashing you should be
able to find out very quickly if it exists or not, no? So if you were
doing a hash join between two tables and one of them had a hash index on
the appropriate field, couldn't you check the index first to see if
there was a match? Granted, you could probably do the same thing with a
B-tree index, but this might be faster in some scenarios.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Lane Van Ingen | 2005-08-30 23:51:58 | Location of pgpass.conf File |
Previous Message | anita.liste | 2005-08-30 21:17:31 | Installation on SLES 9.2 |