ParallelQuery: study how to use the same read snapshot

The Goal

In order to use Parallel query, we need all workers to read the data from the same snapshot.

That is,

• The primary worker would start innodb read snapshot.
• Then, the secondary workers should also use the same snapshot so that they all are reading the same view of the data that the primary has got.

How normal execution does this

Look for ReadView::open.
It seems to be implicitly when we're trying to read the first row.
I suppose there is also some way to force the read view to be allocated explicitly.

(gdb) wher 10

#0  ReadView::open (this=0x7ffff03d6488, trx=0x7ffff03d5c00)

    at /home/psergey/dev-git/12.3-review-vcol/storage/innobase/read/read0read.cc:231

#1  0x0000555556f1636c in row_search_mvcc (buf=0x77ffb4b95450 "\377", mode=PAGE_CUR_G, 

    prebuilt=0x77ffb4b97cd0, match_mode=0, direction=0)

    at /home/psergey/dev-git/12.3-review-vcol/storage/innobase/row/row0sel.cc:4716

#2  0x0000555556c7e4bd in ha_innobase::index_read (this=0x77ffb4b94be8, 

    buf=0x77ffb4b95450 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY)

    at /home/psergey/dev-git/12.3-review-vcol/storage/innobase/handler/ha_innodb.cc:9012

#3  0x0000555556c7f4fe in ha_innobase::index_first (this=0x77ffb4b94be8, 

    buf=0x77ffb4b95450 "\377")

    at /home/psergey/dev-git/12.3-review-vcol/storage/innobase/handler/ha_innodb.cc:9359

#4  0x0000555556c7f734 in ha_innobase::rnd_next (this=0x77ffb4b94be8, 

    buf=0x77ffb4b95450 "\377")

    at /home/psergey/dev-git/12.3-review-vcol/storage/innobase/handler/ha_innodb.cc:9463

#5  0x0000555556745513 in handler::ha_rnd_next (this=0x77ffb4b94be8, 

    buf=0x77ffb4b95450 "\377")

    at /home/psergey/dev-git/12.3-review-vcol/sql/handler.cc:4046

#6  0x00005555560c2950 in rr_sequential (info=0x77ffb403c5c8)

    at /home/psergey/dev-git/12.3-review-vcol/sql/records.cc:509

#7  0x00005555560a4e91 in READ_RECORD::read_record (this=0x77ffb403c5c8)

    at /home/psergey/dev-git/12.3-review-vcol/sql/records.h:77

#8  0x000055555630b8a1 in join_init_read_record (tab=0x77ffb403c4f8)

    at /home/psergey/dev-git/12.3-review-vcol/sql/sql_select.cc:25663

In normal execution this is done...

How to get handler objects in workers

Should the worker get the table name, and then "open the table" like it is currently done in regular execution?

Or should some other way be used, for example do h2= table->file->clone() and then use the h2 in the worker thread? (When handler::clone() was introduced, the clones were only used in the same thread as the "parent" objects. One thing about clones that they currently share TABLE and table->record[0], so one can't use them in parallel. )

Further details

Q1: what if the current transaction has uncommitted data? According to Monty, multiple threads should be able to read through one transaction's uncommitted changes just the same. (A counter example: in MyRocks that won't be possible as uncommitted data is kept in non-thread-safe in-memory MemTable structure that belongs to one thread).

Q2: what about Locking Reads or Transactions that may modify data. At the moment we assume that this will not happen: That is, parallel workers will NOT place any InnoDB row/table/etc locks and will not write any data.

Links

Percona Server has "START TRANSACTION WITH CONSISTENT SNAPSHOT FROM SESSION <session_id>;" which looks like an SQL wrapper around what we need. Study this.