git » mariadb.git » commit 127d595

diff --git a/0007-MDEV-20646.patch b/0007-MDEV-20646.patch
deleted file mode 100644
index 53ca497..0000000
--- a/0007-MDEV-20646.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-commit d4edb0510ec1189f65850bb47977e94ed98b1f71
-Author: Sergei Petrunia <psergey@askmonty.org>
-Date:   Wed Nov 13 18:53:59 2019 +0300
-
-    MDEV-20646: 10.3.18 is slower than 10.3.17
-    
-    Fix incorrect change introduced in the fix for MDEV-20109.
-    
-    The patch tried to compute a more precise estimate for the record_count
-    value in SJ-Materialization-Scan strategy (in
-    Sj_materialization_picker::check_qep).  However the new formula is worse
-    as it produces extremely optimistic results in common cases where
-    SJ-Materialization-Scan should be used)
-    
-    The old formula produces pessimistic results in cases when Sj-Materialization-
-    Scan is unlikely to be a good choice anyway. So, the old behavior is better.
-
-diff --git a/sql/opt_subselect.cc b/sql/opt_subselect.cc
-index aeafc13998a..a8afd952a4d 100644
---- a/sql/opt_subselect.cc
-+++ b/sql/opt_subselect.cc
-@@ -3029,7 +3029,22 @@ bool Sj_materialization_picker::check_qep(JOIN *join,
- 
-     *strategy= SJ_OPT_MATERIALIZE_SCAN;
-     *read_time=    prefix_cost;
--    *record_count= prefix_rec_count / mat_info->rows_with_duplicates;
-+    /*
-+      Note: the next line means we did not remove the subquery's fanout from
-+      *record_count. It needs to be removed, as the join prefix is
-+
-+        ntX  SJM-SCAN(it1 ... itN) | (ot1 ... otN) ...
-+
-+      here, the SJM-SCAN may have introduced subquery's fanout (duplicate rows,
-+      rows that don't have matches in ot1_i). All this fanout is gone after
-+      table otN (or earlier) but taking it into account is hard.
-+
-+      Some consolation here is that SJM-Scan strategy is applicable when the
-+      subquery is smaller than tables otX. If the subquery has large cardinality,
-+      we can greatly overestimate *record_count here, but it doesn't matter as
-+      SJ-Materialization-Lookup is a better strategy anyway.
-+    */
-+    *record_count= prefix_rec_count;
-     *handled_fanout= mat_nest->sj_inner_tables;
-     return TRUE;
-   }
diff --git a/PKGBUILD b/PKGBUILD
index 2557848..29416ef 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,8 +4,8 @@
 pkgbase=mariadb
 pkgname=('mariadb-libs' 'mariadb-clients' 'mariadb' 'mytop')
 pkgdesc='Fast SQL database server, derived from MySQL'
-pkgver=10.4.10
-pkgrel=2
+pkgver=10.4.11
+pkgrel=1
 arch=('x86_64')
 license=('GPL')
 url='https://mariadb.org/'
@@ -19,14 +19,12 @@ validpgpkeys=('199369E5404BD5FC7D2FE43BCBCB082A1BB943DB') # MariaDB Package Sign
 source=("rsync://rsync.osuosl.org/mariadb/mariadb-${pkgver}/source/mariadb-${pkgver}.tar.gz"{,.asc}
         '0001-arch-specific.patch'
         '0002-systemd-sysusers-tmpfiles.patch'
-        '0005-fix-galera_recovery-with-fs.protected_regular-enabled.patch'
-        '0007-MDEV-20646.patch')
-sha256sums=('cd50fddf86c2a47405737e342f78ebd40d5716f0fb32b976245de713bed01421'
+        '0005-fix-galera_recovery-with-fs.protected_regular-enabled.patch')
+sha256sums=('4c076232b99433b09eb3c6d62f607192b3474d022703699b8f6aef4e79de3fb9'
             'SKIP'
             'ce72ea1563ad773e00e8b1c299babea176abae1102827c2f743921e9de615041'
             '3e83467af80fbd53400a201a34fc858b88509ea8e88b10709947eb66545f9457'
-            'c8c801f80924ccb97b499552fe1c532b3ebf8f86cdfc0d23715d4adb1a8810f0'
-            '825d4ab1601c9e97bf24857bcfd8bed2b6d8ad15a4c2411c7867bff2333b09d8')
+            'c8c801f80924ccb97b499552fe1c532b3ebf8f86cdfc0d23715d4adb1a8810f0')
 
 prepare() {
   cd $pkgbase-$pkgver/
@@ -46,9 +44,6 @@ prepare() {
   # fix galera_recovery with fs.protected_regular enabled
   # https://github.com/MariaDB/server/pull/1137
   patch -Np1 < ../0005-fix-galera_recovery-with-fs.protected_regular-enabled.patch
-
-  # MDEV-20646: 10.3.18 is slower than 10.3.17
-  patch -Np1 < ../0007-MDEV-20646.patch
 }
 
 build() {