It seems that setting MAX_FILESIZE only won't trigger split automatically
(need major compaction?). Also using split on when creating the table to
force split seems only works for String type row key. Is there any way else
I can use to make the table auto split for the unit test?
2015-07-09 23:36
Sounds like something else is going wrong. Can you adapt your test by
setting the MAX_FILESIZE very low for your table (so that it splits after 4
or 5 rows are added) and package it up as a unit test?
On Thu, Jul 9, 2015 at 1:44 PM, Yufan Liu yli...@kent.edu wrote:
Just got a chance to revisit
Just got a chance to revisit this issue: I have rebuilt the index and it
still returns the unexpected result. By using the test case, I tried to
insert enough rows to make it auto-split and it reproduces the problem too.
It seems it still has trouble returning last row sorted by first component
of
On further investigation, I believe it should have been working before. I
did a bit of cleanup and attached a new patch to PHOENIX-2096, but this
would only prevent a merge sort when one is not required (basically
improving performance).
Maybe your index is invalid? You can try rebuilding with
The query on test dataset is returning the expected result with the patch.
But on the original dataset (10million rows, 6 regions), it still return
the same unexpected result, I will dig more into this. Thank you, James!
2015-07-02 9:58 GMT-07:00 Yufan Liu yli...@kent.edu:
Sure, let me have a
I'm using 4.4.0-HBase-0.98
2015-07-01 22:31 GMT-07:00 James Taylor jamestay...@apache.org:
Yufan,
What version of Phoenix are you using?
Thanks,
James
On Wed, Jul 1, 2015 at 2:34 PM, Yufan Liu yli...@kent.edu wrote:
When I made more tests, I find that this problem happens after table got
Thanks, Yufan. I found an issue and filed PHOENIX-2096 with a patch. Would
you mind confirming that this fixes the issue you're seeing?
James
On Thu, Jul 2, 2015 at 9:45 AM, Yufan Liu yli...@kent.edu wrote:
I'm using 4.4.0-HBase-0.98
2015-07-01 22:31 GMT-07:00 James Taylor
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 jamestay...@apache.org:
Yes, reverse scan will be leveraged
When I made more tests, I find that this problem happens after table got
split.
Here is the DDL I use to create table and index:
CREATE TABLE IF NOT EXISTS t1 (
uid BIGINT NOT NULL,
timestamp BIGINT NOT NULL,
eventName VARCHAR
CONSTRAINT my_pk PRIMARY KEY (uid, timestamp)) COMPRESSION='SNAPPY';
Yufan,
What version of Phoenix are you using?
Thanks,
James
On Wed, Jul 1, 2015 at 2:34 PM, Yufan Liu yli...@kent.edu wrote:
When I made more tests, I find that this problem happens after table got
split.
Here is the DDL I use to create table and index:
CREATE TABLE IF NOT EXISTS t1 (
uid
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 yli...@kent.edu wrote:
I used the HBase reverse scan to find the last row on the index table. It
returned the expected
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
mmcallis...@homeaway.commailto:mmcallis...@homeaway.com | C: 512.423.7447 |
skype:
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
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:yli...@kent.edu]
Sent: Friday, June 26, 2015 7:19 PM
To:
Thank you anyway, Michael!
2015-06-26 17:21 GMT-07:00 Michael McAllister mmcallis...@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
15 matches
Mail list logo
