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
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
I'd recommend trying with and without the index with a representative data
set in Pherf, our performance testing tool:
https://phoenix.apache.org/pherf.html
Do a lot of your queries filter only on b (i.e. without any filter on a or
a1)? If so, that'll end up being a full table scan. One
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
