Hi Chabot,
"USE_SORT_MERGE_JOIN" hint is supported from v4.3.0 onwards. As your
version is 4.2.2 ,so it is not getting used in your query.
It seems , your stats are corrupted because of region merge or split,
resulting in some regionserver to not receive a hash join cache. Though
stats collection
Actually, the partial rebuild would need to work differently than I
mentioned to handle the case where rows are deleted from the table while
the index is disabled. See my comment here[1] for a pointer to some code
that handles this correctly.
[1]
https://issues.apache.org/jira/browse/PHOENIX-2890?
Hi Julian,
Yes, marking an index as UNUSABLE simply means it won't be considered at
query time. It will still be maintained. If you DISABLE it, then you won't
be hit with the maintenance cost, but we don't have a mechanism to
partially rebuild it. See PHOENIX-2890 and the WIP patch. In theory, if y
Hi all,
Does Phoenix use the same execution path for updating indices mark as
UNUSABLE as it does for USABLE indices (that is, will indices marked as
UNUSABLE require an additional write for every upsert, just as USABLE
indices will)? If maintaining an unsuable index still requires an extra
write,
Hi Aaron,
For commercial distros, you need to talk to the vendor. HDP 2.4.2 has a
very old version of Phoenix - 4.4 which is 4 minor releases back (an eon in
OS time). If you need something with commercial support, maybe you can get
an early access of the next HDP release, but I'd recommend just us
James,
I am working with Amit on this task. We have switched to an 9 node (8 RS)
cluster running HP 2.4.2 with a mostly vanilla install. I think our next steps
are to incorporate Mujtaba's changes into our cluster config and re-run, we'll
factor in your suggestions as well.
Is there a "re
Hi Amit,
Couple more performance tips on top of what Mujtaba already mentioned:
- Use the latest Phoenix (4.8.0). There are some great performance
enhancements in here, especially around usage of DISTINCT. We've also got
some new encoding schemes to reduce table sizes in our encodecolumns branch
wh
I’ve captured the execution plan by running a standalone tool.
[hpSDID@11 deviceId="-" reqId="-" threadId="1"] executing SQL select /*+
USE_SORT_MERGE_JOIN */T1.L,T1.C,T1.A,T1.R,T1.W,T1.P,T1.N,T1.E,T1.S,T1.M, T1.CW,
T1
.T,T1.Y,T1.U FROM "asset_metadata" T1 WHERE R=(SELECT MAX(R) from
"asset_met
I’ve added the hint to the SELECT. Does anyone see anything wrong with this
statement?
select /*+ USE_SORT_MERGE_JOIN
*/T1.L,T1.C,T1.A,T1.R,T1.W,T1.P,T1.N,T1.E,T1.S,T1.M, T1.CW, T1.T,T1.Y,T1.U
FROM "asset_metadata" T1
WHERE R=(SELECT MAX(R) from "asset_metadata" WHERE L=T1.L AND C=T1.C AND
