| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mischa Sandberg <mischa(dot)sandberg(at)telus(dot)net> |
| Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Neil Conway <neilc(at)samurai(dot)com>, 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 22:56:21 |
| Message-ID: | 27799.1115765781@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
Mischa Sandberg <mischa(dot)sandberg(at)telus(dot)net> writes:
> The PG hash join is the simplest possible: build a hash table in memory,
> and match an input stream against it.
> *Hybrid hash* is where you spill the hash to disk in a well-designed
> way. Instead of thinking of it as building a hash table in memory, think
> of it as partitioning one input; if some or all of it fits in memory,
> all the better. The boundary condition is the same.
[ raised eyebrow... ] Apparently you've not read the code. It's been
hybrid hashjoin since we got it from Berkeley. Probably not the best
possible implementation of the concept, but we do understand about spill
to disk.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Glaesemann | 2005-05-10 23:16:53 | Re: Loading a list of SQL scripts with relative paths |
| Previous Message | Mark Lewis | 2005-05-10 22:46:04 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mischa Sandberg | 2005-05-10 23:24:01 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Previous Message | Mark Lewis | 2005-05-10 22:46:04 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |