Re: Hash Joins vs. Bloom Filters / take 2 - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Hash Joins vs. Bloom Filters / take 2
Date
Msg-id d1d768ee-d5af-8d7d-c4c7-53fa4164c478@2ndquadrant.com
Whole thread Raw
In response to Re: Hash Joins vs. Bloom Filters / take 2  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Hash Joins vs. Bloom Filters / take 2  (Jim Finnerty <jfinnert@amazon.com>)
List pgsql-hackers
On 10/01/2018 09:15 AM, Michael Paquier wrote:
> On Thu, Mar 01, 2018 at 07:04:41PM -0500, David Steele wrote:
>> After reviewing the thread I also agree that this should be pushed to
>> 2018-09, so I have done so.
>>
>> I'm very excited by this patch, though.  In general I agree with Peter that
>> a higher rate of false positives is acceptable to save memory.  I also don't
>> see any reason why this can't be tuned with a parameter. Start with a
>> conservative default and allow the user to adjust as desired.
> 
> Not much has happened since last March.  The patch has conflicts in
> regression tests.  Thomas, you are registered as a reviewer of this
> patch.  Are you planning to look at it?
> 
> This is moved to next CF, waiting on author per the rotten bits.
> --

I don't expect to work on this anytime soon, so maybe mark it as 
returned with feedback instead of moving it to the next CF.

I think the idea to push down the bloom filter to the other side of the 
hash join is what would make it much more interesting than the simple 
approach in this patch - but it's also much more work to make it work.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: de-deduplicate code in DML execution hooks in postgres_fdw
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - add pseudo-random permutation function