The PERSISTENTHASH should not make a difference between joins and
selections, and imo hash should be reusable during joins as they are
during selections. I have not noticed what you saw, so maybe someone
else has an explanation. If not, it might even be a bug.

Now, slices and mitosis is another tricky part. Hashes are not working
with slices and that is an issue that we need to address by
redesigning maybe some parts (it might have already been addressed and
I dont know of).

On Fri, Apr 22, 2016 at 12:53 PM, Roberto Cornacchia
<roberto.cornacchia@gmail.com> wrote:
> Actually, the selection can reuse the hash only when mitosis is not active.
> Perhaps this makes sense.
>
> sql>set optimizer='sequential_pipe';
> operation successful (0.830ms)
> sql>select value from obj_string where value = 'apple' limit 1;
> +-------+
> | value |
> +=======+
> | apple |
> +-------+
> 1 tuple (570.217ms)
> sql>select value from obj_string where value = 'apple' limit 1;
> +-------+
> | value |
> +=======+
> | apple |
> +-------+
> 1 tuple (1.991ms)
>
>
> But still, this isn't happening with joins, even with sequential pipe.
> One difference I noticed is that subselect takes both the tid and the
> persistent bat as direct inputs, while subjoin takes the leftfetchjoin
> between the same tid and persistent bat as input. Can that be the reason?
>
>
> On 21 April 2016 at 18:07, Roberto Cornacchia <roberto.cornacchia@gmail.com>
> wrote:
>>
>> I just noticed that PERSISTENTHASH (checked by BAThash) in gdk_private is
>> not defined (commented). But this wouldn't explain the different between
>> selection and join.
>>
>>
>>
>> On 21 April 2016 at 18:02, Roberto Cornacchia
>> <roberto.cornacchia@gmail.com> wrote:
>>>
>>> I noticed a difference between
>>> - a hash-based string selection from a persistent, read-only table
>>> - a hash-based join on the same table and same column
>>>
>>> They both build a hash on the same string column (verified with gdb), but
>>> the select can reuse the hash (second call is almost free), while the join
>>> keeps rebuilding the hash.
>>>
>>> Is this expected?
>>>
>>> Roberto
>>
>>
>
>

> _______________________________________________
> users-list mailing list
> users-list@monetdb.org
> https://www.monetdb.org/mailman/listinfo/users-list
>
_______________________________________________
users-list mailing list
users-list@monetdb.org
https://www.monetdb.org/mailman/listinfo/users-list