phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kumar Palaniappan <kpalaniap...@marinsoftware.com>
Subject Re: Having Global covered Index
Date Mon, 18 Jan 2016 18:12:56 GMT
Thanks James.

Do we need an index on a pk column, since it's a last element in the rowkey, to speed up the
query?   ( because of this, write won't be impacted on that table) we do leverage the call
queue.

Kumar Palaniappan   

> On Jan 18, 2016, at 10:07 AM, James Taylor <jamestaylor@apache.org> wrote:
> 
> See https://phoenix.apache.org/secondary_indexing.html
> 
> Hints are not required unless you want Phoenix to join between the index and data table
because the index isn't fully covered and some of these non covered columns are referenced
in the query.
> 
> bq. Doesnt a single global covered index sufficient for both use cases?
> 
> That depends entirely on the requirements for your use case. If query performance is
"good enough" without the index(es), then you don't need them.
> 
>> On Mon, Jan 18, 2016 at 8:14 AM, Kumar Palaniappan <kpalaniappan@marinsoftware.com>
wrote:
>> 
>> 
>> We have a table
>> 
>> create table t1 ( a bigint not null, a1 bigint not null, b bigint not null, c varchar,
d varchar pk_constraint "t1_pk" (a, a1,b))
>> 
>> 
>> create a global indices as -
>> 
>> create index id_t1 on t1 (b) include (a,a1,c,d) - this one is to speed up filtering
on b since it is the last element in the row key. (I highly doubt we need this)
>> 
>> create index id_t1_c on t1 (c) include (a,d)  - to increase the perf on filtering
the c
>> 
>> 
>> What are the impacts on these indices? does it really make any difference in Phoenix?
do we need to enforce the hints to pick up the index on run time, if we have multiple indices
on a single table?
>> 
>> Doesnt a single global covered index sufficient for both use cases?
> 

Mime
View raw message