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.

1 files changed, 30 insertions, 0 deletions

diff --git a/sql/ha_partition.cc b/sql/ha_partition.cc
index 4ec6f3dfa38..852bcefed3c 100644
--- a/sql/ha_partition.cc
+++ b/sql/ha_partition.cc
@@ -5185,6 +5185,36 @@ int ha_partition::rnd_pos_by_record(uchar *record)
 }
 
 
+/*
+  Determine whether a call to rnd_pos() is expensive
+
+  SYNOPSIS
+    is_rnd_pos_expensive()
+
+  RETURN VALUE
+    FALSE                       No inherent inefficiencies in rnd_pos()
+    TRUE                        rnd_pos() call is inefficient
+
+  DESCRIPTION
+    Some engines, such as Spider, have an inefficient implementation of
+    rnd_pos(), because they need to do a remote access to fetch the
+    single table row.  Determine whether the rnd_pos() implementation
+    for any of the partitions is expensive.
+*/
+
+bool ha_partition::is_rnd_pos_expensive()
+{
+  DBUG_ENTER("ha_partition::is_rnd_pos_expensive");
+  uint i;
+
+  for (i= 0; i < m_tot_parts; i++)
+    if (m_file[i]->ha_is_rnd_pos_expensive())
+      DBUG_RETURN(TRUE);
+
+  DBUG_RETURN(FALSE);
+}
+
+
 /****************************************************************************
                 MODULE index scan
 ****************************************************************************/