Re: [HACKERS] hybrid hash, cont. of development suggestion needed

From: Xun Cheng <xun(at)cs(dot)ucsb(dot)edu>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] hybrid hash, cont. of development suggestion needed
Date: 2000-01-16 23:44:22
Message-ID: 200001162344.PAA01190@hercules.cs.ucsb.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

First I want to thank you for all help I got to my
earlier posting.

>> Right. The hash join uses batching if it estimates that the relation
>> is too large to fit in memory; is that what you call "hybrid"?
>
>I've heard the word "hybrid" being used of a scheme where you hash each
>key of a multi-key index separately and then concatenate the hashes for
>the index. That way you can use the index for accessing also subsets of
>keys by examining only the buxkets with matching hash sections.

In research, there are traditionally three kinds of hash joins:
simple hash, grace hash and hybrid hash. Hybrid is generally considered
to be having a better performance since it is designed to combine
the best behavior of simple hash and grace hash.
It has two phases. In the first the relations are read, hashed into
buckets, and written out, as in grace hash. However, during this phase
a portion of the memory is reserved for an in-memory hash bucket for R (
R is joining with S and R is smaller). This bucket of R will never
be written to disk.

xun

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2000-01-17 00:00:45 docs done Re: [HACKERS] LIBPQ patches ...
Previous Message Bruce Momjian 2000-01-16 22:04:44 Re: [HACKERS] I think we need an explicit parsetree node for CAST