mirror of
https://github.com/MariaDB/server.git
synced 2025-11-04 04:46:15 +01:00
8166a5d33d
When calculate_cond_selectivity_for_table() takes into account multi-
column selectivities from range access, it tries to take-into account
that selectivity for some columns may have been already taken into account.
For example, for range access on IDX1 using {kp1, kp2}, the selectivity
of restrictions on "kp2" might have already been taken into account
to some extent.
So, the code tries to "discount" that using rec_per_key[] estimates.
This seems to be wrong and unreliable: the "discounting" may produce a
rselectivity_multiplier number that hints that the overall selectivity
of range access on IDX1 was greater than 1.
Do a conservative fix: if we arrive at conclusion that selectivity of
range access on condition in IDX1 >1.0, clip it down to 1.
17 lines
514 B
Text
17 lines
514 B
Text
--source include/have_innodb.inc
|
|
# This test is slow on buildbot.
|
|
--source include/big_test.inc
|
|
--source include/default_optimizer_switch.inc
|
|
--source include/not_embedded.inc
|
|
--source ./include/innodb_stable_estimates.inc
|
|
|
|
SET SESSION STORAGE_ENGINE='InnoDB';
|
|
|
|
set @save_optimizer_switch_for_selectivity_test=@@optimizer_switch;
|
|
set optimizer_switch='extended_keys=on';
|
|
|
|
--source selectivity_notembedded.test
|
|
|
|
set optimizer_switch=@save_optimizer_switch_for_selectivity_test;
|
|
|
|
SET SESSION STORAGE_ENGINE=DEFAULT;
|