You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2016/03/27 04:23:25 UTC

[jira] [Commented] (CALCITE-1171) Limit N on JdbcSchema pushdown doesn't seem to work

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

Julian Hyde commented on CALCITE-1171:
--------------------------------------

We never implemented it. No reason why we couldn't. I think we should implement both LIMIT and OFFSET, if possible. For each dialect, we'd have to know whether it supported LIMIT and if so, what is the syntax. Note that some databases use "OFFSET ... FETCH NEXT" (standard SQL, I believe), some use "LIMIT ... OFFSET".

> Limit N on JdbcSchema pushdown doesn't seem to work
> ---------------------------------------------------
>
>                 Key: CALCITE-1171
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1171
>             Project: Calcite
>          Issue Type: Bug
>          Components: avatica, core
>            Reporter: Dan Di Spaltro
>            Assignee: Julian Hyde
>            Priority: Minor
>
> I am exploring the code and came across this situation which I can't decide if it's intended or not.  Programatically, I create a JdbcSchema on a Calcite driver connection, and then execute a single query.  I have a breakpoint in the postgres driver, because I wanted to see how the queries end up before they're sent to PG.  So I started simple, select * from X id = 'foo', which works great.  Then I did a select * from X limit 10.  And I noticed I was getting the correct number of rows back, but when sending to PG it would just send select * from X and then looks like the enumerable code (linq4j) would then chop off the results.  Is there a way to change this behavior, or is this intended?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)