From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, David Steele <david(at)pgmasters(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hash Joins vs. Bloom Filters / take 2 |
Date: | 2018-10-01 10:54:29 |
Message-ID: | d1d768ee-d5af-8d7d-c4c7-53fa4164c478@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2018-10-01 11:19:42 | Re: pgbench - add pseudo-random permutation function |
Previous Message | Michael Paquier | 2018-10-01 10:42:53 | Re: de-deduplicate code in DML execution hooks in postgres_fdw |