[ 
https://issues.apache.org/jira/browse/CALCITE-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090992#comment-17090992
 ] 

Vineet Garg commented on CALCITE-3952:
--------------------------------------

Thanks for the feedback [~julianhyde]. I have few follow-up questions
bq. When we generate the baseline xml file we insert tests in approximately 
alphabetical order. Reduces merge conflicts. Better than editing manually.
How do I regenerate these files automatically? Unlike mvn running the test with 
gradle doesn't seem to generate xml file under target/surefire.

bq. be sure to check for OFFSET. If there is an offset you can’t safely remove 
the Sort
Can you provide an example where it will not be safe? The patch currently (pull 
request is open) checks if input has atmost single row and removes the sort 
only if LIMIT >= 1. I am not sure why offset will change things here.

bq.  I noticed that RelBuilder skips Aggregate if getMaxRowCount <= 1. Maybe it 
could do the same for Sort. And then maybe you wouldn’t need to modify 
SortRemoveRule.
The pull request I have opened has made changes to SortRemoveRule. May be it is 
worthwhile having this logic in RelBuilder as well? Let me know what are your 
thoughts on this.
 

> Improve SortRemoveRule to remove Sort based on rowcount
> -------------------------------------------------------
>
>                 Key: CALCITE-3952
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3952
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Vineet Garg
>            Assignee: Vineet Garg
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a query is guaranteed to produce maximum one row it is safe to remove Sort 
> (along with limit). 
> Example:
> {code:sql}
> select count(*) cs from store_sales where ss_ext_sales_price > 100.00 order 
> by cs limit 100
> {code}
> Although logically equivalent this can greatly benefit physical plans by 
> removing extra operator and avoiding unnecessary data transfer.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to