diff options
author | Jacob Mathew <jacob.mathew@mariadb.com> | 2018-02-19 19:19:03 -0800 |
---|---|---|
committer | Jacob Mathew <jacob.mathew@mariadb.com> | 2018-02-19 21:36:19 -0800 |
commit | 884b83e28fed3d6de2593d5b4121dc23fce7f921 (patch) | |
tree | f56e51de430a099966b3a99cefd9a78ea6057ce8 /sql/handler.h | |
parent | d23fcc427cb4010b33defc69547089afeb9af811 (diff) | |
download | mariadb-git-bb-10.3-MDEV-14500.tar.gz |
MDEV-14500: Support engines without rnd_pos() andbb-10.3-MDEV-14500
engines with inefficient rnd_pos()
Some engines have not implemented rnd_pos(). There are other engines whose
implementation of rnd_pos() is inherently inefficient. Spider is such an
engine, whose implementation of rnd_pos() needs to access a table on a remote
data node to retrieve a single table row.
To address these limitations, a new temporary table has been added to filesort.
When filesort sequentially reads the table being sorted, each row is written to
the filesort temp table in addition to being copied to the sort buffer.
Subsequent calls to rnd_pos() will then access the table row in the filesort
temp table instead of in the table being sorted.
The following logic changes incorporate the new filesort temp table into the
server:
- A new handler method to determine whether a call to the engine's
rnd_pos() is expensive. The default return value is FALSE. Engines without
rnd_pos() or with an inefficient rnd_pos() should return TRUE.
- Create the filesort temp table only if:
- There are no add-on columns for filesort; and
- The engine's implementation of rnd_pos() is expensive.
- Write to the temp table each row that is read from the table being sorted.
- Do subsequent row retrievals that use rnd_pos() on the temp table instead of
on the table being sorted. Upon retrieving a row from the temp table, copy
its column values to the record of the table being sorted.
- Upon completion of retrieval of the sorted result rows, delete the filesort
temp table and free the memory allocated for using it.
The logic changes are in the following areas:
- Table handler.
- Partition engine.
- Spider engine.
- Filesort.
- Read record manager.
Note that these changes only address the use of rnd_pos() by filesort. They do
not address the use of rnd_pos() in other areas such as:
- Quick select.
- Insert.
- Update.
- Window functions.
- Multi Range Read.
Author:
Jacob Mathew.
Reviewer:
Sergei Golubchik.
Diffstat (limited to 'sql/handler.h')
-rw-r--r-- | sql/handler.h | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/sql/handler.h b/sql/handler.h index a96e98c2f84..98e02eaa244 100644 --- a/sql/handler.h +++ b/sql/handler.h @@ -3536,6 +3536,17 @@ public: position(record); return rnd_pos(record, ref); } + /** + Some engines are unable to provide an efficient implementation + for rnd_pos(). Spider is such an engine, as a call to rnd_pos() + needs to access a table on a remote data node to retrieve the + single table row. + */ + virtual bool is_rnd_pos_expensive() + { + /* Engine's rnd_pos() implementation has no inherent inefficiencies */ + return FALSE; + } virtual int read_first_row(uchar *buf, uint primary_key); public: @@ -3545,6 +3556,10 @@ public: int ha_rnd_next(uchar *buf); int ha_rnd_pos(uchar *buf, uchar *pos); inline int ha_rnd_pos_by_record(uchar *buf); + inline bool ha_is_rnd_pos_expensive() + { + return is_rnd_pos_expensive(); + } inline int ha_read_first_row(uchar *buf, uint primary_key); /** |