Thank you, James Taylor，I just found this problem when I looked into
PHOENIX-3578，PHOENIX-3578 may be caused by the fact that the Join SQL is using
SkipScanFilter after dynamic filtering but the sql is also
OrderBy.REV_ROW_KEY_ORDER_BY.
At 2017-01-10 23:47:08, "James Taylor" <jamestay...@apache.org> wrote:
>Because no one has implemented it. It would be a welcome addition and
>probably not too difficult.
>Thanks,
>James
>
>On Tue, Jan 10, 2017 at 7:00 AM 程磊 <comnetw...@163.com> wrote:
>
>> Hi,when I read the following code in OrderBy.complie method, in line
>> 160,it seems that SkipScanFilter can not support
>> OrderBy.REV_ROW_KEY_ORDER_BY,
>>
>> SkipScanFilter still could not support OrderBy.REV_ROW_KEY_ORDER_BY now?
>> and why? :
>>
>>
>>
>>
>>
>> 155 if (isInRowKeyOrder && tracker.isOrderPreserving()) {
>>
>> 156 if (tracker.isReverse()) {
>>
>> 157 // Don't use reverse scan if we're using a skip scan,
>> as our skip scan doesn't support this yet.
>>
>> 158 // REV_ROW_KEY_ORDER_BY scan would not take effect for
>> a projected table, so don't return it for such table types.
>>
>> 159 if
>> (context.getConnection().getQueryServices().getProps().getBoolean(QueryServices.USE_REVERSE_SCAN_ATTRIB,
>> QueryServicesOptions.DEFAULT_USE_REVERSE_SCAN)
>>
>> 160 && !context.getScanRanges().useSkipScanFilter()
>>
>> 161 &&
>> context.getCurrentTable().getTable().getType() != PTableType.PROJECTED
>>
>> 162 &&
>> context.getCurrentTable().getTable().getType() != PTableType.SUBQUERY) {
>>
>> 163 return OrderBy.REV_ROW_KEY_ORDER_BY;
>>
>> 164 }
