You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by James Taylor <ja...@apache.org> on 2017/01/10 15:47:08 UTC
Re: Why SkipScanFilter can not support OrderBy.REV_ROW_KEY_ORDER_BY?
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 程磊 <co...@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 }
Re:Re: Re: Why SkipScanFilter can not support
OrderBy.REV_ROW_KEY_ORDER_BY?
Posted by 程磊 <co...@163.com>.
Ok.I will try to make a patch for PHOENIX-3578, and James Taylor,Could help me review PHOENIX-3453? Thank you very much.
在 2017-01-12 00:13:13，"James Taylor" <ja...@apache.org> 写道：
>Thanks - sounds like you're on to the root cause. Would you mind commenting
>on the JIRA, please? Patches are most welcome too.
>Thanks,
>James
>
>On Wed, Jan 11, 2017 at 12:46 AM 程磊 <co...@163.com> wrote:
>
>>
>>
>>
>>
>> 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" <ja...@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 程磊 <co...@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 }
>>
>>
Re: Re: Why SkipScanFilter can not support OrderBy.REV_ROW_KEY_ORDER_BY?
Posted by James Taylor <ja...@apache.org>.
Thanks - sounds like you're on to the root cause. Would you mind commenting
on the JIRA, please? Patches are most welcome too.
Thanks,
James
On Wed, Jan 11, 2017 at 12:46 AM 程磊 <co...@163.com> wrote:
>
>
>
>
> 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" <ja...@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 程磊 <co...@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 }
>
>
Re:Re: Why SkipScanFilter can not support
OrderBy.REV_ROW_KEY_ORDER_BY?
Posted by 程磊 <co...@163.com>.
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" <ja...@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 程磊 <co...@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 }