The row that is being updated could have the non-default column value for the default column. The update may not choose this column. In that case, TRAF_REPLACE would blindly replace these columns with the default value. It becomes worse if the default column is a timestamp with current_timestamp as default.
Update can implicitly select and update the column value. This could be beneficial in case of non-wide row in aligned format. In case of wide row, hbase format tables are better for update as Ming suggested. Selva From: Liu, Ming (Ming) <[email protected]> Sent: Wednesday, June 6, 2018 5:40 AM To: [email protected]; [email protected] Subject: RE: Upsert on part of columns get traf_merge which cause the performance not good hi, Yuan, You can check a discussion on this at https://lists.apache.org/[email protected]:2016-03, search for 'upsert semantics' topic. Default mode should be MERGE as discussed, it was decided that. Correct behavior is more important than peformance. I think you can create Non-Aligned format table, if the table is very frequently updated, it will be slower for read queries though. Others may have better answer here thanks, Ming From: Liu, Yuan (Yuan) <[email protected]<mailto:[email protected]>> Sent: Wednesday, June 06, 2018 3:33 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Upsert on part of columns get traf_merge which cause the performance not good Hi Trafodioneers, In many cases, we find that "UPDATE" is not that efficient, so sometimes we rewrite the "UPDATE" as "UPSERT". However, if we only write part of columns in upsert, the query plan will get "TRAF_MERGE", which is still not efficient. Only if we write all the columns in upsert, the query plan can get good query plan, such as VSBB_UPSERT. If table has hundrends of columns, this is very complex for users. It is possible that upsert choose "TRAF_REPLACE" by default, at the same time, we keep the values which are not in upsert? Best regards, Yuan
