, key2, value2)
* T1 updates the row (key3, key2, value3) to (key1, key2, value1)
Both of the above scenarios don't seem to have a deterministic behavior.
Best,
Hao
On Fri, Sep 21, 2018 at 2:29 AM, Xiaokai Wang
mailto:xiaokai.wa...@gmail.com>> wrote:
Thanks your reply, Mike.
In o
ng the latest value for that row at scan time will be slow because it
has to do a lot of work at read time.
Mike
On Tue, Sep 18, 2018 at 8:48 AM Xiaokai Wang wrote:
Moved here from JIRA.
Hi guys, I met a problem about the keys locks that almost impacts the
service normal writing.
As we al
for more information about the on-disk design.
>
> If you accumulate too many uncompacted mutations against a given row,
> reading the latest value for that row at scan time will be slow because it
> has to do a lot of work at read time.
>
> Mike
>
> On Tue, Sep 18, 2018 at 8
e information about the on-disk design.
If you accumulate too many uncompacted mutations against a given row, reading
the latest value for that row at scan time will be slow because it has to do a
lot of work at read time.
Mike
On Tue, Sep 18, 2018 at 8:48 AM Xiaokai Wang
mailto:xiaokai.w.
Moved here from JIRA.
Hi guys, I met a problem about the keys locks that almost impacts the service
normal writing.
As we all know, a transaction which get all row_key locks will go on next step
in kudu. Everything looks good, if keys are not concurrent updated. But when
keys are updated by
