Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL

From: Mischa Sandberg <mischa(dot)sandberg(at)telus(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 23:24:01
Message-ID: 1115767441.4281429124b9b@webmail.telus.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> 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.
>
> [ 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.

Apologies. I stopped reading around line 750 (PG 8.0.1) in
src/backend/executor/nodeHashjoin.c

if (!node->hj_hashdone)
{
....
/*
* execute the Hash node, to build the hash table
*/
hashNode->hashtable = hashtable;
(void) ExecProcNode((PlanState *) hashNode);
...

and missed the comment:
/*
* Open temp files for outer batches,
*/

Will quietly go and read twice, talk once.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Daniel Schuchardt 2005-05-10 23:31:46 Re: Delphi - Developers start develop Access components
Previous Message Peter Fein 2005-05-10 23:17:43 JOIN on set of rows?

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Stark 2005-05-10 23:56:15 Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
Previous Message Tom Lane 2005-05-10 22:56:21 Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL