Fix incorrect EST.ROWS estimate (5 vs 9) for HASH JOIN / DISTRIBUTED FOR UPDATE SKIP LOCKED in test sfu.for_update_multi_part_skip_locked

Description

In the sfu.for_update_multi_part_skip_locked test, the estimated row count (EST.ROWS) for a query using HASH JOIN and DISTRIBUTED FOR UPDATE is incorrectly reported as 9, while the expected value is 5.

Actual Result:
The EST.ROWS value is 9.

Expected Result:
The EST.ROWS value should be 5.

Steps to Reproduce

1. Log into the machine.
2. Navigate to the directory: /obdata/data/AndroidTest/ob_opensource_test/tools/deploy
3. Execute the following commands to set up the test environment and run the specific test:

   export OCEANBASE_HOME=/obdata/data/AndroidTest/ob_opensource_test/
   cd ${OCEANBASE_HOME}/tools/deploy
   source activate_obd.sh
   export OBD_SEEKDB_STATUS_FALLBACK_TCP=1
   
   obd test mysqltest test_env --mysqltest-bin=${OCEANBASE_HOME}/deps/3rd/u01/obclient/bin/mysqltest --obclient-bin=${OCEANBASE_HOME}/deps/3rd/u01/obclient/bin/obclient --init-only --init-sql-dir=${OCEANBASE_HOME}/tools/deploy --init-sql-files='init.sql,init_user.sql|root@sys|test'
   obd test mysqltest test_env --mysqltest-bin=${OCEANBASE_HOME}/deps/3rd/u01/obclient/bin/mysqltest --obclient-bin=${OCEANBASE_HOME}/deps/3rd/u01/obclient/bin/obclient --disable-reboot --test-set=sfu.for_update_multi_part_skip_locked
   

4. The test runs the following SQL, where the discrepancy in EST.ROWS is observed:

   USE test;
   
   DROP TABLE IF EXISTS t2;
   DROP TABLE IF EXISTS t1;
   
   CREATE TABLE t1 (
     c1 INT,
     c2 VARCHAR(20),
     c3 INT,
     PRIMARY KEY (c1, c2, c3)
   );
   
   CREATE TABLE t2 (
     c1 INT,
     c2 VARCHAR(20),
     c3 INT,
     PRIMARY KEY (c1, c2)
   );
   
   INSERT INTO t1 VALUES (1,'dkz',3), (2,'dkz',3), (3,'dsr',3);
   INSERT INTO t2 VALUES (1,'dkz',3), (2,'dkz',3), (3,'dsr',3);
   
   SET autocommit = 0;
   SELECT * FROM t1 WHERE c1 = 1 FOR UPDATE;
   COMMIT;
   SET autocommit = 1;
   
   /* Comparison point: Expected EST.ROWS is 5, but SeekDB reports 9 */
   EXPLAIN SELECT t1.c1, t1.c2, t2.c1, t2.c2
   FROM t1, t2
   WHERE t1.c2 = t2.c2
   FOR UPDATE SKIP LOCKED;
   

Environment

• Platform: Windows (mentioned in original title)
• Test Suite: mysqltest
• Specific Test: sfu.for_update_multi_part_skip_locked

Impact

Incorrect row estimation can lead to suboptimal query plan choices, potentially affecting performance for queries involving FOR UPDATE SKIP LOCKED with joins.

Proposed Solution

Investigate and correct the row estimation logic for the specific case of HASH JOIN / DISTRIBUTED FOR UPDATE operations when SKIP LOCKED is used.

Start by running the mysqltest case sfu.for_update_multi_part_skip_locked with the provided setup and EXPLAIN query, then trace the row-estimation path for HASH JOIN and DISTRIBUTED FOR UPDATE SKIP LOCKED. Done means the test reports EST.ROWS as 5 instead of 9 and the regression case passes.