phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Problem in finding the largest value of an indexed column
Date Wed, 01 Jul 2015 01:03:55 GMT
Yes, reverse scan will be leveraged when possible. Make you use NULLS LAST
in your ORDER BY as rows are ordered with nulls first.

On Tue, Jun 30, 2015 at 5:25 PM, Yufan Liu <yliu33@kent.edu> wrote:

> I used the HBase reverse scan to find the last row on the index table. It
> returned the expected result. I would like to know is Phoenix's "ORDER BY"
> and "DESC" implemented based on HBase reverse scan?
>
> 2015-06-26 17:25 GMT-07:00 Yufan Liu <yliu33@kent.edu>:
>
>> Thank you anyway, Michael!
>>
>> 2015-06-26 17:21 GMT-07:00 Michael McAllister <mmcallister@homeaway.com>:
>>
>>>  OK, I’m a Phoenix newbie, so that was the extent of the advice I could
>>> give you. There are people here far more experienced than I am who should
>>> be able to give you deeper advice. Have a great weekend!
>>>
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>> *From:* Yufan Liu [mailto:yliu33@kent.edu]
>>> *Sent:* Friday, June 26, 2015 7:19 PM
>>> *To:* user@phoenix.apache.org
>>> *Subject:* Re: Problem in finding the largest value of an indexed column
>>>
>>>
>>>
>>> Hi Michael,
>>>
>>> Thanks for the advice, for the first one, it's "CLIENT 67-CHUNK PARALLEL
>>> 1-WAY FULL SCAN OVER TIMESTAMP_INDEX; SERVER FILTER BY FIRST KEY ONLY;
>>> SERVER AGGREGATE INTO SINGLE ROW" which is as expected. For the second one,
>>> it's "CLIENT 67-CHUNK SERIAL 1-WAY REVERSE FULL SCAN OVER TIMESTAMP_INDEX;
>>> SERVER FILTER BY FIRST KEY ONLY; SERVER 1 ROW LIMIT" which looks correct,
>>> but still returns the unexpected result.
>>>
>>>
>>>
>>> 2015-06-26 16:59 GMT-07:00 Michael McAllister <mmcallister@homeaway.com
>>> >:
>>>
>>> Yufan
>>>
>>>
>>>
>>> Have you tried using the EXPLAIN command to see what plan is being used
>>> to access the data?
>>>
>>>
>>>
>>> Michael McAllister
>>>
>>> Staff Data Warehouse Engineer | Decision Systems
>>>
>>> mmcallister@HomeAway.com | C: 512.423.7447 | skype:
>>> michael.mcallister.ha <zimmkate@hotmail.com> | webex:
>>> https://h.a/mikewebex
>>>
>>> [image: Description: Description: cid:3410354473_30269081]
>>>
>>> This electronic communication (including any attachment) is
>>> confidential.  If you are not an intended recipient of this communication,
>>> please be advised that any disclosure, dissemination, distribution, copying
>>> or other use of this communication or any attachment is strictly
>>> prohibited.  If you have received this communication in error, please
>>> notify the sender immediately by reply e-mail and promptly destroy all
>>> electronic and printed copies of this communication and any attachment.
>>>
>>>
>>>
>>> *From:* Yufan Liu [mailto:yliu33@kent.edu]
>>> *Sent:* Friday, June 26, 2015 6:31 PM
>>> *To:* user@phoenix.apache.org
>>> *Subject:* Problem in finding the largest value of an indexed column
>>>
>>>
>>>
>>> Hi,
>>>
>>> We have created a table (eg, t1), and a global index of one numeric
>>> column of t1 (eg, timestamp). Now we want to find the largest value of
>>> timestamp, we have tried two approaches:
>>>
>>>
>>> 1. select max(timestamp) from t1; This query takes forever to finish, so
>>> I think it maybe doing a full table scan/comparison .
>>>
>>> 2. select timestamp from t1 order by timestamp desc limit 1; This query
>>> finished fast, but the result it returns is far from the largest value. It
>>> seems it just return the largest value for a certain range of data.
>>>
>>> Did anyone else encounter this issue/have any suggestion?
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Yufan
>>>
>>>
>>>
>>>
>>> --
>>>
>>> best,
>>> Yufan
>>>
>>
>>
>>
>> --
>> best,
>> Yufan
>>
>>
>
>
> --
> best,
> Yufan
>
>

Mime
View raw message