Hi! Is there a way to get last-write-wins semantics based on PRIMARY_KEY and ignoring TIME_INDEX? (ideally, keep the later timestamp, but last insert would be ok too). Scenario: We receive events over NATS, with one consumer writing to greptime in real time and one to parquet. There's a scenario where two independent failures result in an attempt to re-insert the data to greptime with the same primary key and different timestamps. Failure A (these failures can occur in either order): the parquet writer flushes the file but the nats server never receives the ACK. This causes nats server to redeliver the same event, so it will be written to another parquet file with a later timestamp. (timestamp is when the server received the event) Failure B: greptime gets corrupted, or the greptime ingester process fails, and we need to reconstruct database data from parquet. As we process parquet files to send to greptime, the same data record may be sent to greptime twice. Each one has a different timestamp. You might think that the parquet-to-greptime loader could keep an in-memory cache of (primary-key,timestamp) and re-use the first timestamp seen, but that loader might start loading after the "first" parquet, whose data may already be in greptime, so the first row the loader sees is the one with the later timestamp. A hacky way to handle the reload would be to load the data into a different table, then write sql queries to replace the timestamps, then move the files into the primary metrics table. What I think we'll probably do is use the timestamp inside the event (the time when the event was created, not when the server received it) for the TIME_INDEX. That timestamp of course doesn't change even if nats redelivers the event. It's unfortunately less trusted than the server-received timestamp, but we can add server-received time as an extra column in greptime and use it for adjusting times in dashboards if necessary. Thanks for the help!

What I think we’ll probably do is use the timestamp inside the event (the time when the event was created, not when the server received it) for the TIME_INDEX.

I’d recommend this approach. We can also assign a fixed timestamp, like 0, to the time index. But we will lose most benefit of the time index. Since your event has an timestamp naturally, using the event timestamp as time index is a better solution.

Sounds good!