There are few reasons - around corner cases , starting from a region-split
to any minor compactions during write process, general recommendation is to
not use guide posts for query processing - or - disable guideposts so the
consistency is guaranteed
On Tue, Aug 20, 2019 at 11:10 AM jesse wrote:
Yes, that seems to be a trick, the issue is only associated a region.
What could be the causes of guidposts not updated?
On Mon, Aug 19, 2019, 6:40 PM venkata subbarayudu
wrote:
> Did you try with updating table statistics, it may be because some times
> table guideposts are out of sync
>
> Be
You are right, thanks so much, but it’s so limited that I can’t include all
columns due to hundreds of columns existing in one table.
I think covered columns must be queried in global indexes is reasonable, local
index isn’t.
Because we query rowkey from local index first , then get actual row
Did you try with updating table statistics, it may be because some times
table guideposts are out of sync
Below is the SQL to update table stats
Update statistics table
By default above executes asynchronously, hence it may take some time to
update depending on table size
On Tue 20 Aug,
And the table is simple and has no index set up.
On Mon, Aug 19, 2019, 6:03 PM jesse wrote:
> we got some trouble, maybe someone could shed some light on this.
>
> Table has primary key c1, c2 and c3.
> Table is set with SALT_BUCKETS=12. Now it has 14 regions.
>
> The table has a record with c1=
we got some trouble, maybe someone could shed some light on this.
Table has primary key c1, c2 and c3.
Table is set with SALT_BUCKETS=12. Now it has 14 regions.
The table has a record with c1='a', c2='b', c3='c'
If Phoenix query is like:
select * from t where c2='b', it returns some results.
se
It’ll start with 12 regions, but those regions may split as they’re written
to.
On Mon, Aug 19, 2019 at 4:34 PM jesse wrote:
> I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this
> right?
>
> Thanks
>
>
>
I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this right?
Thanks
http://phoenix.apache.org/faq.html#Why_isnt_my_secondary_index_being_used
On 8/19/19 6:06 AM, you Zhuang wrote:
Phoenix-version: 4.14.3-HBase-1.4-SNAPSHOT
hbase-version: 1.4.6
Table:
CREATE TABLE test_phoenix.app (
dt integer not null,
a bigint not null ,
b bigint not null ,
c bigint not null ,
Phoenix-version: 4.14.3-HBase-1.4-SNAPSHOT
hbase-version: 1.4.6
Table:
CREATE TABLE test_phoenix.app (
dt integer not null,
a bigint not null ,
b bigint not null ,
c bigint not null ,
d bigint not null ,
e bigint not null ,
f bigint not null ,
g bigint
We have no problems with that. I mean indexes are used even without hints,
if they're suitable for a query.
Maybe you can share your Phoenix version, query, index definition and exec
plan ?
On Mon, Aug 19, 2019 at 12:46 PM you Zhuang
wrote:
> Yeah, I mean no hint , use appropriate index automati
Yeah, I mean no hint , use appropriate index automatically. I create a local
index and a query with corresponding index column filter in where clause. But
the query doesn’t use index, with index hint it uses it.
12 matches
Mail list logo
