mirror of https://github.com/apache/druid.git
docs: remove outdated druidversion var from a page (#16570)
Co-authored-by: asdf2014 <asdf2014@apache.org>
This commit is contained in:
parent
3fb6ba22e8
commit
8e11adfc6f
|
@ -365,7 +365,7 @@ GROUP BY
|
||||||
Join datasources allow you to do a SQL-style join of two datasources. Stacking joins on top of each other allows
|
Join datasources allow you to do a SQL-style join of two datasources. Stacking joins on top of each other allows
|
||||||
you to join arbitrarily many datasources.
|
you to join arbitrarily many datasources.
|
||||||
|
|
||||||
In Druid {{DRUIDVERSION}}, joins in native queries are implemented with a broadcast hash-join algorithm. This means
|
Joins in native queries are implemented with a broadcast hash-join algorithm. This means
|
||||||
that all datasources other than the leftmost "base" datasource must fit in memory. In native queries, the join condition
|
that all datasources other than the leftmost "base" datasource must fit in memory. In native queries, the join condition
|
||||||
must be an equality. In SQL, any join condition is accepted, but only equalities of a certain form
|
must be an equality. In SQL, any join condition is accepted, but only equalities of a certain form
|
||||||
(see [Joins in SQL](#joins-in-sql)) execute efficiently as part of a native join. For other kinds of conditions, planner will try
|
(see [Joins in SQL](#joins-in-sql)) execute efficiently as part of a native join. For other kinds of conditions, planner will try
|
||||||
|
@ -431,7 +431,7 @@ and how to detect it.
|
||||||
3. One common reason for implicit subquery generation is if the types of the two halves of an equality do not match.
|
3. One common reason for implicit subquery generation is if the types of the two halves of an equality do not match.
|
||||||
For example, since lookup keys are always strings, the condition `druid.d JOIN lookup.l ON d.field = l.field` will
|
For example, since lookup keys are always strings, the condition `druid.d JOIN lookup.l ON d.field = l.field` will
|
||||||
perform best if `d.field` is a string.
|
perform best if `d.field` is a string.
|
||||||
4. As of Druid {{DRUIDVERSION}}, the join operator must evaluate the condition for each row. In the future, we expect
|
4. The join operator must evaluate the condition for each row. In the future, we expect
|
||||||
to implement both early and deferred condition evaluation, which we expect to improve performance considerably for
|
to implement both early and deferred condition evaluation, which we expect to improve performance considerably for
|
||||||
common use cases.
|
common use cases.
|
||||||
5. Currently, Druid does not support pushing down predicates (condition and filter) past a Join (i.e. into
|
5. Currently, Druid does not support pushing down predicates (condition and filter) past a Join (i.e. into
|
||||||
|
|
Loading…
Reference in New Issue