Re: Bloom Filter lookup for hash joins

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bloom Filter lookup for hash joins
Date: 2013-06-26 18:47:48
Message-ID: CAOeZVidS4L4Gw4ZwST9aPXd+2o0kgJY018vmvCC+WULBWeq2kQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 27, 2013 at 12:01 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> I don't think that sounds all that promising. When the hash table does not
> fit in memory, it is either partitioned into multiple passes, each of which
> do fit in memory, or it chooses a different plan altogether.

Yeah, my point is, we could potentially be looking at not bringing in
all of the memory blocks for the hash tables. Even if they are
processed in parts, we still are looking at all of them.

Why not do a local bloom filter lookup, and never bring in the tuples
that are given negative the bloom filter? This could save us some
reads anyhow.

> Do we know
> under what conditions a Bloom filter would be superior to those options, and
> could we reliably detect those conditions?

Yes, this needs to be researched.

Regards,

Atri

--
Regards,

Atri
l'apprenant

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-06-26 18:55:11 Re: Add more regression tests for CREATE OPERATOR
Previous Message Bruce Momjian 2013-06-26 18:46:08 Re: Kudos for Reviewers -- straw poll