Bug #101120 It is necessary to call split() during the parallel read workers running?
Submitted: 11 Oct 2020 15:17 Modified: 13 Oct 2020 12:05
Reporter: haiqing sun Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:8.0.21 OS:Any
Assigned to: CPU Architecture:Any
Tags: Parallel read of index

[11 Oct 2020 15:17] haiqing sun
Description:
After reading the code about the parallel read of index in the MySQL 8.0.21. I have a question about the way of partitioning the leaf page to workers according to the value on the leaf node.

The below of code show that how to decide whether the context need to split:

dberr_t Parallel_reader::Scan_ctx::create_contexts(const Ranges &ranges) {
  size_t split_point{};

  ut_a(max_threads() > 0 && max_threads() <= Parallel_reader::MAX_THREADS);

  if (ranges.size() > max_threads()) {
    split_point = (ranges.size() / max_threads()) * max_threads();
  } else if (m_depth < SPLIT_THRESHOLD) {
    /* If the tree is not very deep then don't split. For smaller tables
    it is more expensive to split because we end up traversing more blocks*/
    split_point = max_threads();
  }

  size_t i{};

  for (auto range : ranges) {
    auto err = create_context(range, i >= split_point);

    if (err != DB_SUCCESS) {
      return (err);
    }

    ++i;
  }

  return (DB_SUCCESS);
}

And when the workers to deal with the context which calls the function split() for the split of context:

    while (err == DB_SUCCESS && !is_error_set()) {
      auto ctx = dequeue();

      if (ctx == nullptr) {
        break;
      }

      auto scan_ctx = ctx->m_scan_ctx;

      if (scan_ctx->is_error_set()) {
        break;
      }

      ctx->m_thread_ctx = thread_ctx;

      if (ctx->m_split) {
        /* For the split of context */
        err = ctx->split();
        /* Tell the other threads that there is work to do. */
        os_event_set(m_event);
      } else {
        err = ctx->traverse();
      }

      ++n_completed;
    }  

The context only includes the persistent cursor of the leaf page for SELECT COUNT(), it is necessary to call split() during the parallel read workers running if the context is not a sub-tree? 

How to repeat:
It is not a bug report but only for the implementation of the core code.
[12 Oct 2020 12:33] MySQL Verification Team
Hi Mr. sun,

Thank you for your question. I must inform you that this is a forum for the bug reports and not a forum for asking questions. However, since you are asking about a logic of the code, we shall try to provide the answer.

When you are counting rows in InnoDB, you have to read all leaf nodes, without using the index. This is due to the fact that InnoDB storage engine is also a MVCC engine. Hence, each transaction has its own independent view of the table(s).

Does it answer your question ???
[12 Oct 2020 15:52] haiqing sun
Thank you very much!

I fully understand what do you mean but my question is that why need to use ctx->split() in the line number of 653 ?

storage/innobase/row/row0pread.cc:653 

void Parallel_reader::worker(size_t thread_id)
...
652       if (ctx->m_split) {
653         err = ctx->split();                                                                                                                               654         /* Tell the other threads that there is work to do. */
655         os_event_set(m_event);                                                                                                                            656       } else {                                                                                                                                            657         err = ctx->traverse();                                                                                                                            658       }

The Parallel_reader::Ctx is a parallel reader execution context of the leaf page and why need to split again?
[13 Oct 2020 12:02] MySQL Verification Team
Thank you, Mr. sun,

We believe that we have provided sufficient answers about algorithms that we are using. We can not go deeper into explanations, nor do we can expose our full internal documentation.
[13 Oct 2020 12:05] haiqing sun
Thanks. Really looking forward to it.