That's what I figured. I think you're right! How hard to try it and see?
Cheers,
Mike
On 2/14/16 3:06 PM, Ildar Absalyamov wrote:
I am not talking about user-facing insert operator, which Abdullah implemented,
but rather LSMBtree-level upset, which seems to be a separate
index-modification operation according to
org.apache.hyracks.storage.am.common.ophelpers.IndexOperation
According to
https://github.com/apache/incubator-asterixdb-hyracks/blob/master/hyracks/hyracks-storage-am-btree/src/main/java/org/apache/hyracks/storage/am/btree/impls/BTree.java#L329-L331
<https://github.com/apache/incubator-asterixdb-hyracks/blob/master/hyracks/hyracks-storage-am-btree/src/main/java/org/apache/hyracks/storage/am/btree/impls/BTree.java#L329-L331>
it seems that it is safe to make changes to the fields as long as they are not keys,
which is indeed the case with metadata changes I was talking about.
On Feb 14, 2016, at 14:49, Mike Carey <[email protected]> wrote:
An upsert would be fine, I would think; perhaps we didn't have it back when
that was done.
(Note that depending on which layer you are talking about, upsert is synonymous
with a
delete and then a (re)insert - though you are probably many layers below my
world at the
user level where that's the case. :-))
On 2/14/16 2:47 PM, Ildar Absalyamov wrote:
A number of metadata-related changes, like creating a new index involves
several stages:
1) Create an index with PENDING_ADD_OP
2) Bulkload the index
3) Delete the index with PENDING_ADD_OP and reinsert it with PENDING_NO_OP
The last operation causes the issue with stats collection for particular index:
sometimes the stats are already persisted before 3) starts executing, so they
are become a subject to cascade delete, hence are lost.
I was wondering why an upset is not an option for step 3 instead of
insert-delete? Are there any complications from transaction logging perspective?
Best regards,
Ildar
Best regards,
Ildar
