MDEV-39942: use actual_rec_per_key in loose scan sj optimization

[bsrikanth-mariadb]

The filtered out value in the explain plan output should be determined based on the actual records per key value in the index. Instead, rec_per_key[] is used.

[gemini-code-assist]

Code Review

This pull request updates Loose_scan_opt in sql/opt_subselect.h to call actual_rec_per_key() instead of directly accessing the rec_per_key array. The reviewer pointed out a potential precision loss issue because the returned floating-point value is assigned to a ulong variable (rpc), which can lead to inaccurate optimizer estimations. A refactoring was suggested to use a double type and avoid assignment inside the conditional statement.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The variable rpc is declared as ulong, but actual_rec_per_key() returns a floating-point value (rec_per_key_t, which is typically double). Assigning it to a ulong causes truncation and precision loss, which can lead to inaccurate cost/cardinality estimations in the optimizer.

Additionally, avoiding assignment inside the if condition improves readability.

        double rpc = s->table->key_info[key].actual_rec_per_key(max_loose_keypart);
        if (rpc > 0)
          records= records / rpc;