It's possible that local indexes could be allowed for atomic upserts, but
global indexes are problematic (in that under load your cluster would
probably die). The reason is that there'd be a cross RS call made for each
row being atomically upserted. If the call hangs due to the RS hosting the
data
This represents a serious shortcoming for our use case. We require some
level of same-row atomic update capability on tables we'd also like to have
global indices on. Our understanding is that running under Tephra doesn't
play well with HBase replication, which we've been intending to use for
Yes, the documentation doesn't reflect the recent changes. Please see
https://issues.apache.org/jira/browse/PHOENIX-3925
Thanks,
Sergey
On Fri, Jun 1, 2018 at 5:39 PM, Miles Spielberg wrote:
> From https://phoenix.apache.org/atomic_upsert.html:
>
> Although global indexes on columns being
>From https://phoenix.apache.org/atomic_upsert.html:
Although global indexes on columns being atomically updated are supported,
> it’s not recommended as a potentially a separate RPC across the wire would
> be made while the row is under lock to maintain the secondary index.
But the parser on
