INSERT ... ON DUPLICATE KEY UPDATE and REPLACE use overly broad column bitmaps

Write_record::prepare_handle_duplicate() unconditionally calls TABLE::use_all_columns() for both INSERT ... ON DUPLICATE KEY UPDATE and REPLACE.

1. The bitmaps are unnecessarily broad. Both read_set and write_set include every column, including unused, unindexed VIRTUAL columns and columns unrelated to the UPDATE assignments. Fetching the required OLD-row data does not require treating every column as both read and written. REPLACE can require a full write bitmap, but the shared blanket operation ignores the different requirements of INSERT, UPDATE and duplicate lookup.

CREATE TABLE t1(id INT PRIMARY KEY, a INT, v INT AS (10 DIV a) VIRTUAL);

INSERT INTO t1(id,a) VALUES (1,1);

--echo # Control: ordinary UPDATE does not need to evaluate v.

UPDATE t1 SET a=0 WHERE id=1;

UPDATE t1 SET a=1 WHERE id=1;

--echo # The equivalent duplicate-key UPDATE unnecessarily evaluates v.

INSERT INTO t(id,a) VALUES (1,1) ON DUPLICATE KEY UPDATE a=0;

DROP TABLE t1;

2. The original INSERT bitmaps are not restored. After handling a duplicate, both maps remain set to all columns when processing subsequent INSERT candidates in the same statement.

CREATE TABLE t1(id INT PRIMARY KEY, a INT, v INT AS (10 DIV a) VIRTUAL);

INSERT INTO t1(id,a) VALUES (1,1);

--echo # The second row inherits bitmaps from preceding duplicate key handling

INSERT INTO t1(id,a) VALUES (1,1),(2,0) ON DUPLICATE KEY UPDATE id=id;

SELECT id,a FROM t1 ORDER BY id;

DROP TABLE t1;

This is particularly problematic for functions such as AI_EMBED(), where each unnecessary evaluation can cost money.