asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: Upsert for metadata changes
Date Sun, 14 Feb 2016 23:17:35 GMT
That's what I figured.  I think you're right!  How hard to try it and see?

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
> According to
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 <> 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
>> 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
>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message