Sent from my iPad
> On 26-Jan-2014, at 4:38, Simon Riggs <simon@2ndQuadrant.com> wrote:
>
>> On 25 January 2014 22:33, Stephen Frost <sfrost@snowman.net> wrote:
>>
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>
>>> AFAICT, there was no consensus in this thread on what to do, which
>>> probably has something to do with the lack of concrete performance
>>> tests presented to back up any particular proposal.
>>
>> This I entirely agree with- more testing and more information on how
>> such a change impacts other workloads would be great. Unfortunately,
>> while I've provided a couple of test cases and seen similar situations
>> on IRC, this is very data-dependent which makes it difficult to have
>> concrete answers for every workload.
>>
>> Still, I'll try and spend some time w/ pg_bench's schema definition and
>> writing up some larger queries to run through it (aiui, the default set
>> of queries won't typically result in a hashjoin) and see what happens
>> there.
>
> The case that action of some kind was needed was clear, for me.
> Hopefully some small improvement can be found from that investigation,
> even if the greatest gain is in some way
I really don't see a way to improve performance in this field except for introducing completely new logic (if we don't
hackNTUP_PER_BUCKET).
My previous patch added bloom filters as an additional layer which was checked before the actual hash join lookup,
hencereducing the number of hash lookups for negatives.
The size of bloom filters required for any significant performance gains and over the additional overhead added because
ofthe additional bloom filter lookup was quite big, hence it did not make any sense to add those.
Upon my discussion with Steven recently, I thought of redoing the patch based on some new tests but I haven't been
reallyable to work on that.
Regards,
Atri
