Re: [QUESTION] Does SQL standard allows project nested fields for aggregate ?

SELECT f0.a, max(f1) FROM t1 GROUP BY f0 I think the problem with the 1st query is that the parser is confused with 'f0' being a table or column name. PostgrelSQL doc [1] suggests to use () to denote column, and the part after () to denote the subfield. In your case, the query should be: SELECT

Re: [ANNOUNCE] Haisheng Yuan joins Calcite PMC

Congratulations! On Tue, Nov 12, 2019 at 1:23 AM Rui Wang wrote: > > Congrats HaiSheng! > > > -Rui > > On Mon, Nov 11, 2019 at 8:05 AM Stamatis Zampetakis > wrote: > > > Congrats Haisheng! > > > > Reviews, code contributions, design discussions, helping users, and many > > more things for

Re: Re: [DISCUSS] On-demand traitset request

> http://mail-archives.apache.org/mod_mbox/calcite-dev/201910.mbox/%3cd75b20f4-542a-4a73-897e-66ab426494c1.h.y...@alibaba-inc.com%3e > > - Haisheng > > -- > 发件人：Jinfeng Ni > 日　期：2019年11月01日 14:10:30 > 收件人： > 主　题：

Re: [DISCUSS] Proposal to add API to force rules matching specific rels

framework, which we > call “On Demand Trait” and implement it as part of the framework so anyone > can be benefited. I hope Haisheng can share a design doc once we have more > concrete ideas. > > > > On Oct 31, 2019, at 11:37 AM, Jinfeng Ni wrote: > > > > Hi Vladi

Re: [DISCUSS] On-demand traitset request

(c, b, a) > Sort(c, b, a) > TableScan R > Sort(c, b, a) > TableScan S > > But if we look at the input traits and has the insight that R already > delivers (b, c, a), we could decide to require (b, c, a) only and avoid > generatin

Re: [DISCUSS] Proposal to add API to force rules matching specific rels

Hi Vladimir, The SubsetTransformer interface and the iterating over the RelNodes within a RelSubset in Drill is exactly implemented to do the trait propagation. We also had to rely on AbstractConverter to fire necessary rule to avoid the CanNotPlan issue. At some point, Calcite community chooses

Re: Re: [DISCUSS] On-demand traitset request

s, we have to enforce some "coordination", to make sure multiple input's trait could work together properly. On Fri, Oct 18, 2019 at 4:38 PM Jinfeng Ni wrote: > > This is an interesting topic. Thanks for bringing up this issue. > > My understanding of Volcano planner is it w

Re: Re: [DISCUSS] On-demand traitset request

This is an interesting topic. Thanks for bringing up this issue. My understanding of Volcano planner is it works in a top-down search mode (the parent asks for certain trait of its child), while the trait propagates in a bottom-up way, as Stamatis explained. IMHO, the issue comes down to the

Re: Re-ordering AND clauses

SQL standard seems to allow the re-ordering of AND clauses; basically, it's "implementation-dependent". In Drill, the run-time will re-order the branches, regardless whether planner does the re-order or not. It's mainly for performance benefit; " exp1 AND expr2" would be reordered into "expr2

Re: [ANNOUNCE] New committer: Zhiqiang He

Congratulations, Zhiqiang! On Fri, Jun 9, 2017 at 1:00 PM, Jacques Nadeau wrote: > Congrats, welcome! > > On Fri, Jun 9, 2017 at 12:57 PM, Eli Levine wrote: > > > Congrats, Ransom! Keep up the good work. > > > > Eli > > > > On Fri, Jun 9, 2017 at 11:49

Re: ways to transform a sql query input value

If you do want to have a planner rule to do such transformation, consider putting the rule in a HepPlanner in stead of VolcanoPlanner, if you have not tried that approach. On Mon, Mar 27, 2017 at 8:50 AM, Julian Hyde wrote: > It’s problematic doing such a transformation in a

Re: JoinToMultiJoinRule usage

That's correct. It's LoptOptimizeJoinRule who is enumerating different join order. JoinToMultiJoinRule is a prerequisite step for LoptOptimizeJoinRule. On Wed, Mar 22, 2017 at 4:35 AM, weijie tong wrote: > I think , this transformation is done by two rules. First >

Re: Ambiguous dynamic star

@Julian, The new test added to test checkAmbiguousUnresolvedStar() looks good to me. I forgot to add such testing, when working on Calcite-1150, though Drill has unit test for such case. One more test we may consider adding. When resolve column reference, regular field has higher priority than

[jira] [Created] (CALCITE-1296) Different classes of datetime should be able to compare.

Jinfeng Ni created CALCITE-1296: --- Summary: Different classes of datetime should be able to compare. Key: CALCITE-1296 URL: https://issues.apache.org/jira/browse/CALCITE-1296 Project: Calcite

Re: How to reduce constant expression in SQL

If you put ReduceExpressionsRule in a HepPlanner, then you do not have to rely the costing factor, since HepPlanner is heuristic-rule based, not cost-based. Actually, Calcite has one unit test in RelOptRuleTest [1] [2], which shows how constant reduce rules work. [1]

Re: Simple quoted identifier : column name vs implicit function call ?

Opened Calcite-1256. https://issues.apache.org/jira/browse/CALCITE-1256 On Tue, May 24, 2016 at 10:05 PM, Julian Hyde <jh...@apache.org> wrote: > Agreed. Log a JIRA. > >> On May 24, 2016, at 9:14 PM, Jinfeng Ni <jinfengn...@gmail.com> wrote: >> >> You are

[jira] [Created] (CALCITE-1256) Quoted reserved identifier should match for column names

Jinfeng Ni created CALCITE-1256: --- Summary: Quoted reserved identifier should match for column names Key: CALCITE-1256 URL: https://issues.apache.org/jira/browse/CALCITE-1256 Project: Calcite

Re: Simple quoted identifier : column name vs implicit function call ?

> called “USER” and see if you get the same results. > > By a similar argument, I deduce that you are trying Calcite-in-Drill (case > insensitive) rather than raw Calcite (case sensitive). > > Then yes, open a JIRA. > > Julian > > >> On May 24, 2016, at 3:50 PM, Jinfeng N

Re: [jira] [Commented] (CALCITE-1150) Create the a new DynamicRecordType, avoiding star expansion when working with this type

@Julian, Your comment makes sense to me. I put a short doc describing the expected behavior for this feature. The doc link is put in CALCITE-1150. Please take a look. Jinfeng On Wed, Apr 20, 2016 at 1:06 PM, Julian Hyde (JIRA) wrote: > > [ >

Calcite master branch has failed unit test?

On commit: git log commit 9f6f23de06791a3d2de1672b55bfdf7d6396bc78 Failed tests: SqlToRelConverterTest.testCorrelationNotExistsAndFilter:1692 plan expected:<...alFilter(condition=[[NOT(IS NOT NULL($12)])]) LogicalJoi...> but was:<...alFilter(condition=[[IS NULL($12])])

Re: Assertion check in RelOptTableImpl.create()

Hyde <jh...@apache.org> wrote: > >> I don’t think it would do any harm if DrillTable implements >> ScannableTable. The method could throw UnsupportedOperationException if you >> don’t intend to use it. >> >> > On Jan 8, 2016, at 9:58 PM, Jinfeng Ni <jin

Re: Assertion check in RelOptTableImpl.create()

Jan 8, 2016, at 9:58 PM, Jinfeng Ni <jinfengn...@gmail.com> wrote: >> >> Thanks for the explanation, Julian. >> >> The places where I want to create an instance of RelOptTable is not in >> SqlValidator or SqlToRelConverter. Rather, it's in a RelOptRule,

Re: Assertion check in RelOptTableImpl.create()

le(“CUSTOMERS”) > > But such “free floating” tables cannot implement themselves in that way. > Therefore this method is only for kinds of tables that know how to get to > their own data: TranslatableTable, ModifiableTable, ScannableTable. > > Julian > > >> On Jan 7,

Re: Loose ends before 1.6

Hi Julian, I'll submit a PR for CALCITE-975, and maybe CALCITE-976 which comes from Mehant. Could you please assign CALCITE-978 and CALCITE-977 to Jason Altekruse? Those patches actually came from him, and for some reason, I could not assign Calcite JIRA to him. Thanks, Jinfeng On Thu, Jan

Assertion check in RelOptTableImpl.create()

Does anyone know why one of the static create() methods in RelOptTableImpl has the following assertion check (to check table is instance of TranslatableTable, or ScannableTable, or ModifiableTable) [1], while the rest of create() methods do not do such check? [2] Looks like

Re: [calcite] [CALCITE-966] VolcanoPlanner should clear ruleNames in order to avoid… (#167)

Hi Julian, Thanks for the reminder. I just added the comment per your suggestion to the JIRA case. Regards, Jinfeng On Tue, Dec 1, 2015 at 1:26 PM, Julian Hyde wrote: > Jinfeng, > > When you check in a fix to master branch and mark a JIRA case fixed, > please add a comment

Re: About NULL's position in order by

Julian, I'm trying to see if CALCITE-969/970 may have any impact on Drilll side. I assume that the following logic happens in Calcite's execution side, right? " Currently ORDER BY x DESC is equivalent to ORDER BY x DESC NULLS LAST " On 1.4.0, for "ORDER BY x DECS", I saw the