[MDEV-31788] Factor out code repeat in functions calling spider_check_and_init_casual_read() Created: 2023-07-28  Updated: 2023-11-28

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - Spider
Fix Version/s: 10.4, 10.5, 10.6, 10.11, 11.0, 11.1, 11.2

Type: Task Priority: Major
Reporter: Yuchen Pei Assignee: Yuchen Pei
Resolution: Unresolved Votes: 1
Labels: None

Attachments: File ft_read_internal.cc     File index_first_map_internal.cc     File index_last_internal.cc     File index_read_last_map_internal.cc     File index_read_map_internal.cc     File multi_range_read_next_first.cc     File multi_range_read_next_next.cc     File range_read_first_internal.cc     File rnd_next_internal.cc     GIF File screen.gif    
Issue Links:
Relates
relates to MDEV-26151 Documentation on spider_casual_read i... Closed
relates to MDEV-31787 Clean up and code documentation of ca... Closed
Epic Link: Spider Refactoring

 Description   

The following ha_spider methods inside ha_spider.cc call spider_check_and_init_casual_read()

ft_read_internal multi_range_read_next_first
index_first_map_internal multi_range_read_next_next
index_last_internal range_read_first_internal
index_read_last_map_internal rnd_next_internal
index_read_map_internal

Near the callsite is about 80 lines of repeated code. Part of the repeated region is also a common pattern found in other spider files and functions. They need to be factored out.

See the attached gif for an IDE demo, as well as attached .cc files with these functions extracted out (at 11.0 941f91edbc3d3a0a184b9bfc58d5e4042c4b65f1).



 Comments   
Comment by Yuchen Pei [ 2023-07-28 ]

The cleanup is a bit more involved than I expected which is why I opened this ticket separately from MDEV-31787.

We can just factor out the portion in the gif, but it is not a "logical" block by it self, but rather a block before a for loop, and the if branch inside the for loop. There are (often minor) differences in the else branches, which may not be real differences, but require a bit more effort to the cleanup properly.

For example, I suspect the following are not real differences, and just redundancy in data structure

--- /home/ycp/source/mariadb-server/mdev-26151/repeats/rnd_next_internal.cc	2023-07-28 12:49:48.384561252 +1000
+++ /home/ycp/source/mariadb-server/mdev-26151/repeats/ft_read_internal.cc	2023-07-28 12:49:56.304500405 +1000
      } else {
+        uint dbton_id = share->use_sql_dbton_ids[roop_count];
+        spider_db_handler *dbton_hdl = dbton_handler[dbton_id];
         SPIDER_CONN *conn = conns[roop_count];
-        ulong sql_type;
-        sql_type= SPIDER_SQL_TYPE_SELECT_SQL;
-        spider_db_handler *dbton_hdl = dbton_handler[conn->dbton_id];

I suspect share->use_sql_dbton_ids[roop_count] and conn->dbton_id are always the same value.

Another issues is the pattern in calls to spider_ping_table_mon_from_table(), and the patterns like the following in setup and teardown of queries

        pthread_mutex_lock(&conn->mta_conn_mutex);
        SPIDER_SET_FILE_POS(&conn->mta_conn_mutex_file_pos);
        conn->need_mon = &need_mons[roop_count];
        DBUG_ASSERT(!conn->mta_conn_mutex_lock_already);
        DBUG_ASSERT(!conn->mta_conn_mutex_unlock_later);
        conn->mta_conn_mutex_lock_already = TRUE;
        conn->mta_conn_mutex_unlock_later = TRUE;
        if ((error_num = spider_db_set_names(this, conn, roop_count)))
        {
          DBUG_ASSERT(conn->mta_conn_mutex_lock_already);
          DBUG_ASSERT(conn->mta_conn_mutex_unlock_later);
          conn->mta_conn_mutex_lock_already = FALSE;
          conn->mta_conn_mutex_unlock_later = FALSE;
          SPIDER_CLEAR_FILE_POS(&conn->mta_conn_mutex_file_pos);
          pthread_mutex_unlock(&conn->mta_conn_mutex);

They come in variants (sometimes missing the set / clear file pos part, sometimes without assigning to conn->need_mon) and is scattered all around the codebase, and need a proper cleanup based on understanding (see also my previous attempt in MDEV-29502 https://github.com/MariaDB/server/commit/3b5cecbacd46ea8607b4e5379633e60a98d71bc5). Therefore we defer this ticket to later, maybe when relevant to another task

Generated at Thu Feb 08 10:26:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.