From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hash Joins vs. Bloom Filters / take 2 |
Date: | 2018-03-02 00:04:41 |
Message-ID: | 0fa826ad-6f18-cd43-a9b8-d3db9d5c198b@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/1/18 6:52 PM, Tomas Vondra wrote:
> On 03/02/2018 12:31 AM, Andres Freund wrote:
>>
>>
>> On March 1, 2018 3:22:44 PM PST, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>>>
>>>
>>> On 03/01/2018 11:01 PM, Andres Freund wrote:
>>>> Hi,
>>>>
>>>> On 2018-02-20 22:23:54 +0100, Tomas Vondra wrote:
>>>>> So I've decided to revive the old patch, rebase it to current
>>> master,
>>>>> and see if we can resolve the issues that killed it in 2016.
>>>>
>>>> There seems to be some good discussion in the thread. But the patch
>>>> arrived just before the last commitfest and certainly isn't a trivial
>>>> cleanup patch. Therefore I think it should be moved to the next CF?
>>>>
>>>
>>> It isn't a massive invasive patch either, though, so I object to moving
>>> it to 2018-09 right away.
>>
>> Why do we have rules around not submitting large stuff to the last
>> cf, if we just not follow through? We're neck deep in patches that
>> are older. And you've already gotten a fair bit of feedback..
>>
>
> It was not my intention to break (or even bend) the CF rules, of course.
> I haven't considered the patch to be "large stuff", while you do. I see
> Peter Geoghegan agrees with your conclusion on another thread, so go
> ahead and move it to 2018-09.
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.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-03-02 00:12:25 | Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug |
Previous Message | Bruce Momjian | 2018-03-02 00:03:00 | Re: Better Upgrades |