You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Quesada Lopez (JIRA)" <ji...@apache.org> on 2019/03/29 14:28:00 UTC
[jira] [Comment Edited] (CALCITE-2959) Support collation on struct
fields
[ https://issues.apache.org/jira/browse/CALCITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805023#comment-16805023 ]
Ruben Quesada Lopez edited comment on CALCITE-2959 at 3/29/19 2:27 PM:
-----------------------------------------------------------------------
Thanks for the feedback.
Just to give a "full" example, the EnhancedScan operator that I'm talking about would allow us to do even more complicated things, like for example:
{code}
SELECT p.name, p.address.city, p.address.street FROM Person p ORDER BY p.address.city ASC, p.address.street DESC
{code}
which would translate in something like
{code}
EnhancedScan(table=Person, sort=$2.city ASC, $2.street DESC) // --> Collation [2.2 ASC, 2.0 DESC]?
{code}
so the query would not have a comparison operator at composite field level, but instead individual comparison operators as composite's inner fields level.
was (Author: rubenql):
Thanks for the feedback.
Just to give a "full" example, the EnhancedScan operator that I'm talking about would allow us to do even more complicated things, like for example:
{code}
SELECT p.name, p.address.city, p.address.street FROM Person p ORDER BY p.address.city ASC, p.address.street DESC
{code}
which would translate in something like
{code}
EnhancedScan(table=Person, sort=$2.city ASC, $2.street DESC) // --> Collation [2.2 ASC, 2.0 DESC]?
{code}
> Support collation on struct fields
> ----------------------------------
>
> Key: CALCITE-2959
> URL: https://issues.apache.org/jira/browse/CALCITE-2959
> Project: Calcite
> Issue Type: New Feature
> Reporter: Ruben Quesada Lopez
> Priority: Major
>
> Currently, the class {{RelFieldCollation}} is used to define _"the ordering of one field of a RelNode whose output is to be sorted"_. This representation can hold only "simple" fields. In case of struct fields, a projection needs to be applied in order to reference the struct field as a simple one. For example, given this table:
> {code}
> CREATE TYPE Address AS (
> street VARCHAR(20) NOT NULL,
> zipcode VARCHAR(20) NOT NULL,
> city VARCHAR(20) NOT NULL);
> CREATE TABLE Person (
> id VARCHAR(20) NOT NULL,
> name VARCHAR(20) NOT NULL,
> address Address NOT NULL);
> {code}
> With a SQL query such as: "{{SELECT p.name, p.address.city FROM Person p ORDER BY p.address.city}}" the pseudo-plan generated would look like:
> {code}
> Sort(1) // --> Collation: [1]
> Project(0=$1, 1=$2.city)
> Scan(table=Person)
> {code}
> However, what would happen if we had a specific Scan operator that would guarantee us that the records would be scanned already ordered by address.city? Something like:
> {code}
> EnhancedScan(table=Person, sort=$2.city) // --> Collation???
> {code}
> The collation of such an operator cannot be represented with the current Calcite capabilities (RelFieldCollation), because it would not be a "simple" field, but a struct field, i.e. we would need a new collation abstraction to represent it, e.g. [2.city] or [2.2]
> I would like to open the discuss to see if / how we could find a solution to represent this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)