You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Mujtaba Chohan (JIRA)" <ji...@apache.org> on 2016/06/22 18:20:16 UTC
[jira] [Updated] (PHOENIX-3023) Slow performance when limit queries
are executed in parallel by default
[ https://issues.apache.org/jira/browse/PHOENIX-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mujtaba Chohan updated PHOENIX-3023:
------------------------------------
Assignee: Samarth Jain
> Slow performance when limit queries are executed in parallel by default
> -----------------------------------------------------------------------
>
> Key: PHOENIX-3023
> URL: https://issues.apache.org/jira/browse/PHOENIX-3023
> Project: Phoenix
> Issue Type: Bug
> Reporter: Mujtaba Chohan
> Assignee: Samarth Jain
>
> After [this|https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=54362430d71be788d515944573572624628a09b6] commit, limit queries are executed in parallel which causes performance to be ~5-10x slower. Providing a serial hint fixes it though.
> After commit:
> {code}
> select * from WIDE_PK order by mypk DESC limit 1; // this takes ~400ms
> CLIENT 1280-CHUNK 1996304 ROWS 6380181208 BYTES PARALLEL 4-WAY REVERSE FULL SCAN OVER WIDE_PK SERVER 1 ROW LIMIT CLIENT MERGE SORT CLIENT 1 ROW LIMIT
> {code}
> Before commit:
> {code}
> select * from WIDE_PK order by mypk DESC limit 1; // this takes ~40ms
> CLIENT 1280-CHUNK 1996304 ROWS 6380181208 BYTES SERIAL 4-WAY REVERSE FULL SCAN OVER WIDE_PK SERVER 1 ROW LIMIT CLIENT MERGE SORT CLIENT 1 ROW LIMIT
> {code}
> Test was done on a single node machine running HBase 0.98.17. DDL used was
> {code}CREATE TABLE WIDE_PK (MYPK CHAR(500) NOT NULL PRIMARY KEY,CF.column1 INTEGER,CF.column2 INTEGER,CF.column3 INTEGER,CF.column4 INTEGER,CF.column5 INTEGER) SALT_BUCKETS=4 with phoenix.stats.guidepost.width of 5000000
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)