# Question regarding Query.jl @join implementation
**URL:** https://discourse.julialang.org/t/question-regarding-query-jl-join-implementation/18145
**Category:** Data
**Tags:** question
**Created:** [November 29, 2018, 3:33pm UTC](https://discourse.julialang.org/t/question-regarding-query-jl-join-implementation/18145 "2018-11-29T15:33:51Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@gbenatt92](https://discourse.julialang.org/u/gbenatt92)
#### Post date: [November 29, 2018, 3:33pm UTC](https://discourse.julialang.org/t/question-regarding-query-jl-join-implementation/18145/1 "2018-11-29T15:33:51Z")
Hi! I’ve sent this question over a DM to professor @davidanthoff, but it’s better suited here.
Regarding the [Query.jl](https://github.com/queryverse/Query.jl) package, I’d like to know what are the implementations of `@join` and `@groupjoin`, how efficient they are, and how they work under the lazy streaming format.
I’m really curious about this since joining tables efficiently is a really old problem that has [many different approaches](https://en.wikipedia.org/wiki/Join_(SQL)#Implementation), and the package works on so many different table types.
Thanks a lot for your time!
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [November 29, 2018, 5:12pm UTC](https://discourse.julialang.org/t/question-regarding-query-jl-join-implementation/18145/2 "2018-11-29T17:12:11Z")
You can see the implementation for `@join` [here](https://github.com/queryverse/QueryOperators.jl/blob/a312c00824d82a568512d8e32985bdaa79f55937/src/enumerable/enumerable_join.jl#L33) and for `@groupjoin` [here](https://github.com/queryverse/QueryOperators.jl/blob/a312c00824d82a568512d8e32985bdaa79f55937/src/enumerable/enumerable_groupjoin.jl#L33).
Both use a hash join algorithm. In the LINQ terminology one can classify a query operator’s execution model as immediate vs deferred, and streaming vs non-streaming ([here](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/classification-of-standard-query-operators-by-manner-of-execution) is the exact discussion). Both `@join` and `@groupjoin` have a deferred, non-streaming execution model in our implementation right now. What that means is that the first call to `iterate` will trigger full iteration of both sources for the join, and a complete materialization of the output of the join.
That could actually be improved, though: those implementations could be changed so that at least one of the join sources is not fully iterated in the first call to `iterate`, and instead properly streamed.
Our medium term project (that we are kind of starting now) is to create another backend for [Query.jl](https://github.com/queryverse/Query.jl) that is specific to tabular sources, and then provide a full query optimizer that can pick more efficient algorithms, depending on the query one is trying to execute. Don’t expect anything in the next couple of months, but we are trying out different designs etc. right now.