MDEV-39405: store the necessary plugin-engines optimizer costs

[bsrikanth-mariadb]

store the necessary plugin-engines optimizer costs that are used by the query into the context, so that the replay server uses the same while computing query cost

[gemini-code-assist]

Code Review

This pull request enhances the optimizer context replay mechanism by capturing and storing storage engine-specific optimizer costs. It introduces logic to identify relevant storage engines for a query and generates the corresponding global configuration statements. The review feedback correctly identifies several potential memory leaks where hashes are not freed during early returns and suggests optimizations for the cost-storing logic to improve efficiency and safety.

[spetrunia]

I had to look up what is this. It seems to be the plugin for @@default_storage_engine.
Any reason why we need it in the context?

I assume we need plugins for the tables we're querying, plugin for in-memory temp.table, plugin for on-disk temp.table.

[bsrikanth-mariadb]

Yes, this should be cleaned.

[spetrunia]

What's the point of using DB_NAME_KEY here? It looks confusing.
Why not LEX_STRING?

[spetrunia]

or LEX_CSTRING ...

[bsrikanth-mariadb]

yes, used LEX_CSTRING. Also removed TABLE_NAME_KEY, and DB_NAME_KEY, and instead using LEX_CSTRING there as well.

[spetrunia]

When we're looking at the query's tables:

  const LEX_CSTRING *engine_name= plugin_name(tbl->table->s->db_plugin);

We can get the plugin name, table's hton and hton->optimizer_costs.
This seems to be everything that we need to dump the costs.
(I assume the plugin is locked at this point because the query uses it. Is this correct? )

Question: why do we need to iterate plugins separately and compare name to see if the plugin was used, etc?

[spetrunia]

create table t20 (a int, b int) engine=rocksdb partition by hash(a) partitions 2;
set optimizer_record_context=1;
select * from t20 where a=333;
select * from information_schema.optimizer_context\G

no ROCKSDB.OPTIMIZER_DISK_READ_COST here...
I saw it inserting "partition" as the plugin name.

create table t21 (a int, b int) engine=rocksdb;
set optimizer_record_context=1;
select * from t21 where a=333;
select * from information_schema.optimizer_context\G

Now I can see: SET GLOBAL ROCKSDB.OPTIMIZER_DISK_READ_COST=10.24

Check handler->partition_ht().

[bsrikanth-mariadb]

create table t20 (a int, b int) engine=rocksdb partition by hash(a) partitions 2;
set optimizer_record_context=1;
select * from t20 where a=333;
select * from information_schema.optimizer_context\G

no ROCKSDB.OPTIMIZER_DISK_READ_COST here... I saw it inserting "partition" as the plugin name.

create table t21 (a int, b int) engine=rocksdb;
set optimizer_record_context=1;
select * from t21 where a=333;
select * from information_schema.optimizer_context\G

Now I can see: SET GLOBAL ROCKSDB.OPTIMIZER_DISK_READ_COST=10.24

Check handler->partition_ht().

Yes, using handler->partition_ht() is giving the underlying storage engine name for both partitioned and non-partitioned tables.