phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yufan Liu <yli...@kent.edu>
Subject Re: Problem in finding the largest value of an indexed column
Date Wed, 01 Jul 2015 18:20:43 GMT
I have tried to use query "SELECT timestamp FROM t1 ORDER BY timestamp DESC
NULLS LAST LIMIT 1". But it still returns the same unexpected result. There
seems to be some internal problems related.

2015-06-30 18:03 GMT-07:00 James Taylor <jamestaylor@apache.org>:

> 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
>>
>>
>


-- 
best,
Yufan

Mime
View raw message