From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: bloom filter in Hash Joins with batches |
Date: | 2015-12-28 10:52:29 |
Message-ID: | CAKJS1f-s0vsx6B0cftvT6HrjUmwJvKkX==MWzuZKLfeSPAC6NQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28 December 2015 at 23:44, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:
> On 12/28/2015 11:38 AM, David Rowley wrote:
>
>> If so, then a filter with all 1 bits set should be thrown away, as
>>
> it'll never help us, and the filter should generally become more
>> worthwhile as it contains a higher ratio of 0 bits vs 1 bits. Of
>> course we don't have a count of how many Tuples matched each bit, so
>> this is based on the assumption that each bit matches an equal number
>> of Tuples. Are you saying this is not an assumption that we should
>> make?
>>
>
> Sure we should check that. All I'm saying is it has nothing to do with the
> first problem described in the first part of the e-mail.
Okay. I was merely suggesting this method as an alternative to checking
tracking and checking the usefulness of the filter during the hash probe. I
assumed that tracking and checking the usefulness during the hash probe
won't be free, and that it may be better if we can estimate or determine
the expected usefulness of the filter before the probe stage, and throw it
away before we waste cycles using it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-12-28 11:17:52 | Re: [PATCH] Refactoring of LWLock tranches |
Previous Message | Tomas Vondra | 2015-12-28 10:44:15 | Re: WIP: bloom filter in Hash Joins with batches |