mirror of
https://github.com/archlinuxarm/PKGBUILDs.git
synced 2025-03-19 00:21:40 +00:00
extra/mariadb to 10.4.11-1
This commit is contained in:
parent
ef03a0650b
commit
99c838b91f
2 changed files with 3 additions and 53 deletions
extra/mariadb
|
@ -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;
|
||||
}
|
|
@ -8,8 +8,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/'
|
||||
|
@ -24,14 +24,12 @@ source=("rsync://rsync.osuosl.org/mariadb/mariadb-${pkgver}/source/mariadb-${pkg
|
|||
'0001-arch-specific.patch'
|
||||
'0002-systemd-sysusers-tmpfiles.patch'
|
||||
'0005-fix-galera_recovery-with-fs.protected_regular-enabled.patch'
|
||||
'0007-MDEV-20646.patch'
|
||||
'0001-libatomic.patch')
|
||||
sha256sums=('cd50fddf86c2a47405737e342f78ebd40d5716f0fb32b976245de713bed01421'
|
||||
sha256sums=('4c076232b99433b09eb3c6d62f607192b3474d022703699b8f6aef4e79de3fb9'
|
||||
'SKIP'
|
||||
'ce72ea1563ad773e00e8b1c299babea176abae1102827c2f743921e9de615041'
|
||||
'3e83467af80fbd53400a201a34fc858b88509ea8e88b10709947eb66545f9457'
|
||||
'c8c801f80924ccb97b499552fe1c532b3ebf8f86cdfc0d23715d4adb1a8810f0'
|
||||
'825d4ab1601c9e97bf24857bcfd8bed2b6d8ad15a4c2411c7867bff2333b09d8'
|
||||
'1c7360453b6e964c6546cbbb10fff697f6227554eba716b2a1df74f7c2613d95')
|
||||
|
||||
prepare() {
|
||||
|
@ -53,9 +51,6 @@ prepare() {
|
|||
# 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
|
||||
|
||||
if [[ $CARCH == arm || $CARCH == armv6h ]]; then
|
||||
patch -p1 -i ../0001-libatomic.patch
|
||||
fi
|
||||
|
|
Loading…
Reference in a new issue