[
https://issues.apache.org/jira/browse/IGNITE-25162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-25162:
----------------------------------------
Description:
Seems a bit optimization can be applied if correlate contains in left input of
join, in such a case no need to clear right side (hash store in case of hash
join). If no more items available from left input of upper correlated nested
loop join - seems right input need not to store items more and can clear
appropriate store. All kind of join types need to be covered by tests. Probably
also if left side have not contains correlates (check whole plan attached) and
less than Commons#IN_BUFFER_SIZE - no need to re-request it each time.
Partial plan example:
{noformat}
HashJoin
condition: =(SS_SOLD_DATE_SK, D_DATE_SK)
joinType: inner
est. row count: 79851
Exchange
distribution: affinity[tableId=31, zoneId=31][0]
est. row count: 959175
TableScan
table: [PUBLIC, STORE_SALES]
filters: =($cor4.C_CUSTOMER_SK, SS_CUSTOMER_SK)
fields: [SS_SOLD_DATE_SK, SS_CUSTOMER_SK]
est. row count: 959175
TableScan
table: [PUBLIC, DATE_DIM]
filters: AND(=(D_YEAR, 2000), >=(D_MOY, 3), <=(D_MOY, +(3, 3)))
fields: [D_DATE_SK, D_YEAR, D_MOY]
est. row count: 6081
{noformat}
was:
Seems a bit optimization can be applied if correlate contains in left input of
join, in such a case no need to clear right side (hash store in case of hash
join). If no more items available from left input of upper correlated nested
loop join - seems right input need not to store items more and can clear
appropriate store. All kind of join types need to be covered by tests.
Partial plan example:
{noformat}
HashJoin
condition: =(SS_SOLD_DATE_SK, D_DATE_SK)
joinType: inner
est. row count: 79851
Exchange
distribution: affinity[tableId=31, zoneId=31][0]
est. row count: 959175
TableScan
table: [PUBLIC, STORE_SALES]
filters: =($cor4.C_CUSTOMER_SK, SS_CUSTOMER_SK)
fields: [SS_SOLD_DATE_SK, SS_CUSTOMER_SK]
est. row count: 959175
TableScan
table: [PUBLIC, DATE_DIM]
filters: AND(=(D_YEAR, 2000), >=(D_MOY, 3), <=(D_MOY, +(3, 3)))
fields: [D_DATE_SK, D_YEAR, D_MOY]
est. row count: 6081
{noformat}
> Sql. No need to rewind right input for AbstractRightMaterializedJoinNode
> implementors if correlates are present in left input
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-25162
> URL: https://issues.apache.org/jira/browse/IGNITE-25162
> Project: Ignite
> Issue Type: Task
> Components: sql
> Affects Versions: 3.0
> Reporter: Evgeny Stanilovsky
> Priority: Major
> Labels: ignite-3
> Attachments: corr_plan.txt
>
>
> Seems a bit optimization can be applied if correlate contains in left input
> of join, in such a case no need to clear right side (hash store in case of
> hash join). If no more items available from left input of upper correlated
> nested loop join - seems right input need not to store items more and can
> clear appropriate store. All kind of join types need to be covered by tests.
> Probably also if left side have not contains correlates (check whole plan
> attached) and less than Commons#IN_BUFFER_SIZE - no need to re-request it
> each time.
> Partial plan example:
> {noformat}
> HashJoin
> condition: =(SS_SOLD_DATE_SK, D_DATE_SK)
> joinType: inner
> est. row count: 79851
> Exchange
> distribution: affinity[tableId=31, zoneId=31][0]
> est. row count: 959175
> TableScan
> table: [PUBLIC, STORE_SALES]
> filters: =($cor4.C_CUSTOMER_SK, SS_CUSTOMER_SK)
> fields: [SS_SOLD_DATE_SK, SS_CUSTOMER_SK]
> est. row count: 959175
> TableScan
> table: [PUBLIC, DATE_DIM]
> filters: AND(=(D_YEAR, 2000), >=(D_MOY, 3), <=(D_MOY, +(3, 3)))
> fields: [D_DATE_SK, D_YEAR, D_MOY]
> est. row count: 6081
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
