[
https://issues.apache.org/jira/browse/IGNITE-18206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18206:
---------------------------------------
Description:
Currently, 2-phase aggregate is used even for aggregates with DISTINCT and/or
ORDER BY clauses. This is possible because of unnatural resulting row produced
by a MAP aggregate: in a single column it accumulates all rows belonging to a
particular group.
Such an approach causes errors in cost calculation, as well as closes the door
for further optimizations, like reusing BinaryTuple for sql row, because of a
complex structure of the row.
As a first step, let's prohibit using of 2-phase aggregates for cases where
collection of rows for particular row should be preserved in order to compute
the final result (DISTINCT|SORTED aggregates).
was:
Currently, 2-phase aggregate is used even for aggregates with DISTINCT and
ORDER BY clauses. This is possible because of unnatural resulting row produced
by a MAP aggregate: in a single column it accumulates all rows belonging to a
particular group.
Such an approach causes errors in cost calculation, as well as closes the door
for further optimizations, like reusing BinaryTuple for sql row, because of a
complex structure of the row.
As a first step, let's prohibit using of 2-phase aggregates for cases where
collection of rows for particular row should be preserved in order to compute
the final result (DISTINCT&SORTED aggregates).
> Sql. Prohibit using of DISTINCT|SORTED 2-phase aggregates
> ---------------------------------------------------------
>
> Key: IGNITE-18206
> URL: https://issues.apache.org/jira/browse/IGNITE-18206
> Project: Ignite
> Issue Type: Improvement
> Components: sql
> Reporter: Konstantin Orlov
> Priority: Major
> Labels: ignite-3
>
> Currently, 2-phase aggregate is used even for aggregates with DISTINCT and/or
> ORDER BY clauses. This is possible because of unnatural resulting row
> produced by a MAP aggregate: in a single column it accumulates all rows
> belonging to a particular group.
> Such an approach causes errors in cost calculation, as well as closes the
> door for further optimizations, like reusing BinaryTuple for sql row, because
> of a complex structure of the row.
> As a first step, let's prohibit using of 2-phase aggregates for cases where
> collection of rows for particular row should be preserved in order to compute
> the final result (DISTINCT|SORTED aggregates).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
