[
https://issues.apache.org/jira/browse/CALCITE-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880888#comment-15880888
]
Gian Merlino edited comment on CALCITE-1601 at 2/23/17 5:34 PM:
----------------------------------------------------------------
Hey Julian,
I haven't reviewed the patch (I still haven't wrapped my head around how
DateRangeRules is supposed to work) but I tried it in Druid and this test case
failed:
{code}
testQuery(
"SELECT COUNT(*) FROM druid.foo\n"
+ "WHERE\n"
+ " EXTRACT(YEAR FROM __time) <> 2000 AND ("
+ " (EXTRACT(YEAR FROM __time) = 2000 AND EXTRACT(MONTH FROM
__time) IN (2, 3, 5))\n"
+ " OR (EXTRACT(YEAR FROM __time) = 2001 AND EXTRACT(MONTH FROM
__time) = 1)\n"
+ " )",
ImmutableList.<Query>of(
Druids.newTimeseriesQueryBuilder()
.dataSource(CalciteTests.DATASOURCE1)
.intervals(QSS(new Interval("2001-01-01/P1M")))
.granularity(QueryGranularities.ALL)
.aggregators(AGGS(new CountAggregatorFactory("a0")))
.context(TIMESERIES_CONTEXT_DEFAULT)
.build()
),
ImmutableList.of(
new Object[]{3L}
)
);
{code}
The query got planned into
{code}
BindableValues(tuples=[[{ 0 }]]
{code}
so I think that means the predicate was incorrectly simplified to "false".
Without DateRangeRules.FILTER_INSTANCE, the result is correct. (Although of
course in that case the query doesn't match the expected query, as the filter
ends up a regular filter rather than "intervals" filter)
was (Author: gian):
Hey Julian,
I haven't reviewed the patch (I still haven't wrapped my head around how
DateRangeRules is supposed to work) but I tried it in Druid and this test case
failed:
{code}
testQuery(
"SELECT COUNT(*) FROM druid.foo\n"
+ "WHERE\n"
+ " EXTRACT(YEAR FROM __time) <> 2000 AND ("
+ " (EXTRACT(YEAR FROM __time) = 2000 AND EXTRACT(MONTH FROM
__time) IN (2, 3, 5))\n"
+ " OR (EXTRACT(YEAR FROM __time) = 2001 AND EXTRACT(MONTH FROM
__time) = 1)\n"
+ " )",
ImmutableList.<Query>of(
Druids.newTimeseriesQueryBuilder()
.dataSource(CalciteTests.DATASOURCE1)
.intervals(QSS(new Interval("2001-01-01/P1M")))
.granularity(QueryGranularities.ALL)
.aggregators(AGGS(new CountAggregatorFactory("a0")))
.context(TIMESERIES_CONTEXT_DEFAULT)
.build()
),
ImmutableList.of(
new Object[]{3L}
)
);
{code}
The query got planned into
{code}
BindableValues(tuples=[[{ 0 }]]
{code}
so I think that means the predicate was incorrectly simplified to "false".
Without DateRangeRules.FILTER_INSTANCE, the result is correct.
> DateRangeRules loses OR filters
> -------------------------------
>
> Key: CALCITE-1601
> URL: https://issues.apache.org/jira/browse/CALCITE-1601
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.11.0
> Reporter: Gian Merlino
> Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> I'm not sure why, but DateRangeRules can lose some filters. For example in
> this query:
> {code}
> SELECT COUNT(*) FROM druid.foo WHERE EXTRACT(YEAR FROM __time) = 2000 AND
> EXTRACT(MONTH FROM __time) IN (2, 3, 5)
> {code}
> The filter gets resolved to __time >= 2000-02-01 and __time < 2000-03-01,
> losing the months "3" and "5". Removing DateRangeRules.FILTER_INSTANCE from
> the planner's rule set stops this from happening.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
