[jira] [Commented] (PHOENIX-2270) Implement Drill-specific rule for first level server-side sort

["Maryann Xue (JIRA)" <ji...@apache.org>]

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

Maryann Xue commented on PHOENIX-2270:
--------------------------------------

[~jnadeau] Implemented this in https://github.com/jacques-n/drill/pull/4, but not sure if the sort on the Drill side is a merge instead of real sort. Could you please verify?
The query plan is (also printed by the test case):
{code}
00-00    Screen
00-01      Project(B=[$0], E1=[$1], E2=[$2], R=[$3])
00-02        SelectionVectorRemover
00-03          Sort(sort0=[$1], dir0=[DESC])
00-04            Project(B=[$0], E1=[$1], E2=[$2], R=[$3])
                   PhoenixServerSort(sort0=[$1], dir0=[DESC])
                     PhoenixTableScan(table=[[PHOENIX, A, BEER]], filter=[>=($1, 1)])
00-05              Phoenix
	{
  "head" : {
    "version" : 1,
    "generator" : {
      "type" : "ExplainHandler",
      "info" : ""
    },
    "type" : "APACHE_DRILL_PHYSICAL",
    "options" : [ {
      "kind" : "LONG",
      "type" : "SESSION",
      "name" : "planner.width.max_per_node",
      "num_val" : 2
    } ],
    "queue" : 0,
    "resultMode" : "EXEC"
  },
  "graph" : [ {
    "pop" : "jdbc-scan",
    "@id" : 0,
    "scans" : [ "CgMKATASMQoNc2NhblByb2plY3RvchIgAP8EBAQBGAIBAhkCATACRTECGQIBMAJFMgIZAgEwAVISJQoKY29sdW1uSW5mbxIXBAAAAAFCAAAAAkUxAAAAAkUyAAAAAVISFwoSX05vbkFnZ3JlZ2F0ZVF1ZXJ5EgEBEiUKBV9Ub3BOEhyMAUAAAP8AAQAARRkCAP8EBAAAAAEABSQyLkUxKvABCilvcmcuYXBhY2hlLmhhZG9vcC5oYmFzZS5maWx0ZXIuRmlsdGVyTGlzdBLCAQgBElMKPG9yZy5hcGFjaGUucGhvZW5peC5maWx0ZXIuU2luZ2xlQ0ZDUUtleVZhbHVlQ29tcGFyaXNvbkZpbHRlchITFwQCAhkCATACRTEDBYAAAAEGAxJpCjBvcmcuYXBhY2hlLnBob2VuaXguZmlsdGVyLkNvbHVtblByb2plY3Rpb25GaWx0ZXISNQAAABUfiwgAAAAAAAAAMwAAId/b9AEAAAABAAAAFR+LCAAAAAAAAAAzAAAh39v0AQAAAAAAMgwIABD//////////384AUAB" ],
    "config" : {
      "type" : "phoenix",
      "url" : "jdbc:phoenix:localhost",
      "enabled" : true
    },
    "table" : "A.BEER",
    "userName" : "",
    "cost" : 0.0
  }, {
    "pop" : "project",
    "@id" : 4,
    "exprs" : [ {
      "ref" : "`B`",
      "expr" : "`B`"
    }, {
      "ref" : "`E1`",
      "expr" : "`E1`"
    }, {
      "ref" : "`E2`",
      "expr" : "`E2`"
    }, {
      "ref" : "`R`",
      "expr" : "`R`"
    } ],
    "child" : 0,
    "initialAllocation" : 1000000,
    "maxAllocation" : 10000000000,
    "cost" : 50.0
  }, {
    "pop" : "external-sort",
    "@id" : 3,
    "child" : 4,
    "orderings" : [ {
      "expr" : "`E1`",
      "order" : "DESC",
      "nullDirection" : "UNSPECIFIED"
    } ],
    "reverse" : false,
    "initialAllocation" : 20000000,
    "maxAllocation" : 10000000000,
    "cost" : 50.0
  }, {
    "pop" : "selection-vector-remover",
    "@id" : 2,
    "child" : 3,
    "initialAllocation" : 1000000,
    "maxAllocation" : 10000000000,
    "cost" : 50.0
  }, {
    "pop" : "project",
    "@id" : 1,
    "exprs" : [ {
      "ref" : "`B`",
      "expr" : "`B`"
    }, {
      "ref" : "`E1`",
      "expr" : "`E1`"
    }, {
      "ref" : "`E2`",
      "expr" : "`E2`"
    }, {
      "ref" : "`R`",
      "expr" : "`R`"
    } ],
    "child" : 2,
    "initialAllocation" : 1000000,
    "maxAllocation" : 10000000000,
    "cost" : 50.0
  }, {
    "pop" : "screen",
    "@id" : 0,
    "child" : 1,
    "initialAllocation" : 1000000,
    "maxAllocation" : 10000000000,
    "cost" : 50.0
  } ]
}
{code} 

> Implement Drill-specific rule for first level server-side sort
> --------------------------------------------------------------
>
>                 Key: PHOENIX-2270
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2270
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Maryann Xue
>            Assignee: Maryann Xue
>              Labels: calcite, drill
>
> Phoenix should have a physical operator that executes a sort on the server-side which Drill can leverage when re-ordering is necessary. Unlike PHOENIX-2269 which is clearing going to be more efficient to let Phoenix handle, the sort is more of a gray area. Phoenix will be faster in the way it does the scan within the coprocessor, but it still needs to return the same number of rows. This process puts a pretty heavy burden on the region server as well. We should measure performance with and without Phoenix doing the sort. One potential scenario that may be a win for Phoenix is if the rows are already partially sorted and Phoenix can take advantage of this (which is not currently the case).



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