phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serega Sheypak <serega.shey...@gmail.com>
Subject Select by first part of composite primary key, is it effective?
Date Mon, 01 Feb 2016 21:16:17 GMT
Hi, here is my table DDL:
CREATE TABLE IF NOT EXISTS id_ref
(
   id1     VARCHAR   NOT NULL,
   value1  VARCHAR,

   id2     VARCHAR NOT NULL,
   value2  VARCHAR
   CONSTRAINT id_ref_pk  PRIMARY KEY (id1, id2)
)IMMUTABLE_ROWS=true,SALT_BUCKETS=100, VERSIONS=1, TTL=691200

I'm trying to analyze result of explain:

explain select id1, value1, id2, value2 from id_ref where id1 = 'xxx'

. . . . . . . . . . . . . . . . . . . . . . .> ;

*+------------------------------------------+*

*| **                  PLAN                  ** |*

*+------------------------------------------+*

*| *CLIENT 100-CHUNK PARALLEL 100-WAY RANGE SCAN OVER ID_REF
[0,'1fd5c44a75549162ca1602dda55f6d129cab61a6']* |*

*| *CLIENT MERGE SORT                       * |*

*+------------------------------------------+*


What happens? Client spawns 100 parallel scans (because of bucketing) and
waits for 100 responses?

Is it effective? What is the right way to optimize such query pattern:
"select by first part of primary key"? Reduce the amount of buckets? I get
exeption a while after restarting app:


*Task org.apache.phoenix.job.JobManager$JobFutureTask@60a40644 rejected
from org.apache.phoenix.job.JobManager$1@58e3fe9aRunning, pool size = 128,
active threads = 121, queued tasks = 5000, completed tasks = 2629565*

Mime
View raw message