Skip to content

MDEV-37207: dumping tables for multi delete query doesn't work always #4197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 4 commits into from
Closed

MDEV-37207: dumping tables for multi delete query doesn't work always #4197

wants to merge 4 commits into from

Conversation

bsrikanth-mariadb
Copy link
Contributor 

when doing multiple DELETE on tables:
-> if there was data to delete, then no ddls were dumped to the trace.
-> However, when there was no data that is being deleted from the tables,
   then ddls of the tables were getting dumped to the trace.

The problem is that store_tables_context_in_trace() is not getting
invoked, when there was data to delete from the tables. Although, there
was no error when executing the delete query, the result of basic cleanup was
non-zero and failure of the the result check was prohibiting from invoking
store_tables_context_in_trace() method.

Removed this additional result check for invoking
store_tables_context_in_trace() from mysql_execute_command().

@bsrikanth-mariadb
MDEV-36483: store ddls in the optimizer trace
71dba7d 
This feature stores the ddls of the tables/views that are used in
a query, to the optimizer trace. It is currently controlled by a
system variable store_ddls_in_optimizer_trace, and is not enabled
by default. All the ddls will be stored in a single json array, with each
element having table/view name, and the associated create definition
of the table/view.

The approach taken is to read global query_tables from the thd->lex,
and read them in reverse. Create a record with table_name, ddl of
the table and add the table_name to the hash,
along with dumping the information to the trace.
dbName_plus_tableName is used as a key,
and the duplicate entries are not added to the hash.

The main suite tests are also run with the feature enabled, and they
all succeed.
@bsrikanth-mariadb
MDEV-36483: store ddls in the optimizer trace
14b12ff 
This feature stores the ddls of the tables/views that are used in
a query, to the optimizer trace. It is currently controlled by a
system variable store_ddls_in_optimizer_trace, and is not enabled
by default. All the ddls will be stored in a single json array, with each
element having table/view name, and the associated create definition
of the table/view.

The approach taken is to read global query_tables from the thd->lex,
and read them in reverse. Create a record with table_name, ddl of
the table and add it to the hash, along with dumping the information
to the trace. dbName_plus_tableName is used as a key,
and the duplicate entries are not added to the hash.

The main suite tests are also run with the feature enabled, and they
all succeed.
@bsrikanth-mariadb
MDEV-36511: Dump basic stats of a table to trace
45acb67 
This feature stores the basic stats of the base tables that are used in
a query, to the optimizer trace. This feature is also controlled by
optimizer_record_context, and is not enabled by default. The stats
such as num_of_records present in the table, indexes if present
then their names, along with the average number of records_per_key
with in each index are dumped to the trace. Additionally, stats from
range analysis of the queries are also dumped into the trace

The approach taken here is to extend the existing function
store_tables_context_in_trace() and add new dump_stats_to_trace()
to opt_trace_ddl_info.cc Several new tests are added to
opt_trace_store_stats.test
@bsrikanth-mariadb
MDEV-37207: dumping tables for multi delete query doesn't work always
b576b8f 
when doing multiple DELETE on tables:
-> if there was data to delete, then no ddls were dumped to the trace.
-> However, when there was no data that is being deleted from the tables,
   then ddls of the tables were getting dumped to the trace.

The problem is that store_tables_context_in_trace() is not getting
invoked, when there was data to delete from the tables. Although, there
was no error when executing the delete query, the result of basic cleanup was
non-zero and failure of the the result check was prohibiting from invoking
store_tables_context_in_trace() method.

Removed this additional result check for invoking
store_tables_context_in_trace() from mysql_execute_command().
@bsrikanth-mariadb bsrikanth-mariadb force-pushed the 12.1-MDEV-36483-dump-ddls-of-tables-views branch from deb8e78 to db937cc Compare July 29, 2025 11:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
MariaDB Corporation
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@bsrikanth-mariadb