James Taylor commented on PHOENIX-1556:

Wow, this is really awesome, [~maryannxue]. I love the tests. A couple of 
- Should UNION_DISTINCT_FACTOR be 1.0 since we only support UNION ALL currently?
+        if (!all) {
+            rows *= UNION_DISTINCT_FACTOR;
+        }
- What's the reasoning behind stripSkipScanFilter? Is that removed because it's 
effect is already incorporated into the bytes scanned estimate?
- Should RowCountVisitor have a method for distinct? In particular, there's an 
optimization we have when doing a distinct on the leading PK columns which 
impacts cost. This optimization is not identified until runtime, so we might 
need to tweak the code so we know about it at compile time. This could be done 
in a separate patch.
- Somewhat orthogonal to your pull (but maybe building on top of it), do you 
think it'd be possible to prevent a query from running that's "too expensive" 
(assuming "too expensive" would be identified by a config property)? Something 
to keep in mind - I can file a separate JIRA for this.

> Base hash versus sort merge join decision on cost
> -------------------------------------------------
>                 Key: PHOENIX-1556
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1556
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Maryann Xue
>            Priority: Major
>              Labels: CostBasedOptimization
>         Attachments: PHOENIX-1556.patch
> At compile time, we know how many guideposts (i.e. how many bytes) will be 
> scanned for the RHS table. We should, by default, base the decision of using 
> the hash-join verus many-to-many join on this information.
> Another criteria (as we've seen in PHOENIX-4508) is whether or not the tables 
> being joined are already ordered by the join key. In that case, it's better 
> to always use the sort merge join.

This message was sent by Atlassian JIRA

Reply via email to