Re: [Maria-discuss] MariaDB 10.5.18: Performance-Problems with CONCAT
Hello William Edwards,
yes we are affected and had to revert to version 10.5.16 to keep
rebuilding our lookup/search-tables at night.
Am 04.01.2023 um 19:58 schrieb William Edwards:
Op 4 jan. 2023 om 16:12 heeft Johannes Ody het volgende
geschreven:
I'm german. Please excuse my bad english.
MariaDB version 10.5.18 is much slower than version 10.5.16 in
string-manipulation (CONCAT).
Are you hit by MDEV-29988?
In version 10.5.16 my code in the bottom needs for 800 records in
tmp_tartikel_live 1-2 seconds.
In version 10.5.18 my code needs for 800 records in tmp_tartikel_live 20-30
seconds.
In version 10.5.16 my code needs for 26000 records in tmp_tartikel_live 5-6
minutes. It is ok.
In version 10.5.18 my code needs for 26000 records in tmp_tartikel_live more
than 2 hours and
was terminating by the system and was not ready.
The execution-time glows much more than linear.
The calling script is internal for maintenance-work at night.
The purpose of this code is to build our search-tables in MySQL (concordance).
The code must work for strings with special characters in the coding-systems html
(), ansi and utf-8.
In german and france we have the special characters:
and so on.
I have found other users with performance-problems in MariaDB version 10.5.18,
and they also use CONCAT:
https://dba.stackexchange.com/questions/284073/query-performance-drop-after-upgrade-to-mariadb-10-5-group-concat-join
My code is the following:
/*#JODY_20221010
Die Datenbank muss fuer diesen Code auf Kollektion=latin1_swedish_ci
eingestellt sein.
ALTER DATABASE d03a5b1c COLLATE latin1_swedish_ci;
Das CHARACTER SET scheint nicht so wichtig zu sein.
*/
/*
#JODY_20211228 (ACHTUNG): Diese Datei muss ASCII-Codiert sein (nicht UTF8)
Funktion zum Loeschen von HTML-Tags. Kann nur vom browser aus
installiert werden.
* /
DROP PROCEDURE IF EXISTS mysql_log;*/
DROP FUNCTION IF EXISTS mysql_striptags;
DROP FUNCTION IF EXISTS mysql_replace_utf8_sonderzeichen;
DROP FUNCTION IF EXISTS mysql_replace_single_char;
DROP FUNCTION IF EXISTS mysql_replace_char;
DROP FUNCTION IF EXISTS mysql_replace_umlaute;
/*DROP FUNCTION IF EXISTS mysql_delete_fuellwoerter;*/
DELIMITER $$
/*CREATE PROCEDURE mysql_log(strText VARCHAR(255))
BEGIN
INSERT INTO debugout(cText) VALUES (strText);
END$$*/
CREATE FUNCTION mysql_striptags(strParam TEXT)
RETURNS TEXT
DETERMINISTIC
BEGIN
DECLARE str TEXT;
DECLARE posOpen INT;
DECLARE posClose INT;
SET str = strParam;
loop1: LOOP
SET posOpen = LOCATE("<", str);
SET posClose = LOCATE(">", str, posOpen);
/*#JODY_20211228 Wenn posOpen 0 ist, dann ist posClose auch
immer 0.*/
IF posClose = 0 THEN
LEAVE loop1;
END IF;
SET str = CONCAT(LEFT(str, posOpen - 1), " ", MID(str, posClose +
1));
END LOOP loop1;
RETURN str;
END$$
/*#JODY_20220201:
Die Moeglichkeit zur URL-Erzeugung mit UTF8-Sonderzeichen besteht darin,
dass ein Anwender Strings
aus einem Eingabefeld in die Zwischenablage kopiert und dann im URL-Feld
des Browsers einfuegt.
Dann stehen in der URL z.B. fuer
CONCAT(CHAR(195), CHAR(164))
Das Problem ist also die Eingabe von Sonderzeichen im URL-Feld des
Browsers.*/
CREATE FUNCTION mysql_replace_utf8_sonderzeichen(strParam TEXT)
RETURNS TEXT
DETERMINISTIC
BEGIN
DECLARE str TEXT;
DECLARE nPos INT;
DECLARE nOrd INT;
DECLARE strChar VARCHAR(2);
SET str = strParam;
SET nPos = 1;
loop_for: LOOP
SET nPos = LOCATE(CHAR(195), str, nPos); /*
ACHTUNG (#JODY_20220201):
Hier kommen auch Positionen auf ein einfaches a zurueck. Liegt
an MySQL. Diese brauche
ich hier zwar nicht. Aber der Code kann damit umgehen. Durch
das LOCATE spare ich mir aber
fuer die grosse Menge an Zeichen die Schleifendurchlaeufe.*/
IF nPos = 0 THEN
LEAVE loop_for;
END IF;
SET strChar = MID(str, nPos, 1);
SET nPos = nPos + 1;
IF ORD(strChar) != 195 THEN
ITERATE loop_for;
END IF;
SET strChar = MID(str, nPos, 1);
SET nOrd = ORD(strChar);
IF nOrd >= 132 AND nOrd <= 188 THEN
SET str = REPLACE(str, CONCAT(CHAR(195), strChar), CHAR(nOrd +
64));
SET nPos = nPos + 1;
END IF;
END LOOP;
RETURN str;
END$$
/*
ACHTUNG (#JODY_20220120):
Da strNewStr auch nur Blanks enthalten darf/kann, kann hier nicht mit
CHAR(2) gearbeitet werden.
Variablen vom Typ CHAR(x) waeren bei einem Wert von z.B.
Re: [Maria-discuss] MariaDB 10.5.18: Performance-Problems with CONCAT
Hi, Johannes, Try the next release (expected in about a month) where https://jira.mariadb.org/browse/MDEV-29988 is fixed. Regards, Sergei VP of MariaDB Server Engineering and secur...@mariadb.org On Jan 04, Johannes Ody wrote: > I'm german. Please excuse my bad english. > MariaDB version 10.5.18 is much slower than version 10.5.16 in > string-manipulation (CONCAT). > In version 10.5.16 my code in the bottom needs for 800 records in > tmp_tartikel_live 1-2 seconds. > In version 10.5.18 my code needs for 800 records in tmp_tartikel_live > 20-30 seconds. > In version 10.5.16 my code needs for 26000 records in tmp_tartikel_live > 5-6 minutes. It is ok. > In version 10.5.18 my code needs for 26000 records in tmp_tartikel_live > more than 2 hours and > was terminating by the system and was not ready. > The execution-time glows much more than linear. > The calling script is internal for maintenance-work at night. > The purpose of this code is to build our search-tables in MySQL > (concordance). > The code must work for strings with special characters in the > coding-systems html (), ansi and utf-8. > In german and france we have the special characters: > > > > > > and so on. > > I have found other users with performance-problems in MariaDB version > 10.5.18, and they also use CONCAT: > > https://dba.stackexchange.com/questions/284073/query-performance-drop-after-upgrade-to-mariadb-10-5-group-concat-join > > My code is the following: > /*#JODY_20221010 > Die Datenbank muss fuer diesen Code auf > Kollektion=latin1_swedish_ci eingestellt sein. > ALTER DATABASE d03a5b1c COLLATE latin1_swedish_ci; > Das CHARACTER SET scheint nicht so wichtig zu sein. > */ > > /* > #JODY_20211228 (ACHTUNG): Diese Datei muss ASCII-Codiert sein > (nicht UTF8) > Funktion zum Loeschen von HTML-Tags. Kann nur vom browser aus > installiert werden. > * / > DROP PROCEDURE IF EXISTS mysql_log;*/ > DROP FUNCTION IF EXISTS mysql_striptags; > DROP FUNCTION IF EXISTS mysql_replace_utf8_sonderzeichen; > DROP FUNCTION IF EXISTS mysql_replace_single_char; > DROP FUNCTION IF EXISTS mysql_replace_char; > DROP FUNCTION IF EXISTS mysql_replace_umlaute; > /*DROP FUNCTION IF EXISTS mysql_delete_fuellwoerter;*/ > > DELIMITER $$ > > /*CREATE PROCEDURE mysql_log(strText VARCHAR(255)) > BEGIN > INSERT INTO debugout(cText) VALUES (strText); > END$$*/ > > CREATE FUNCTION mysql_striptags(strParam TEXT) > RETURNS TEXT > DETERMINISTIC > BEGIN > DECLARE str TEXT; ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] MariaDB 10.5.18: Performance-Problems with CONCAT
> Op 4 jan. 2023 om 16:12 heeft Johannes Ody het volgende
> geschreven:
>
> I'm german. Please excuse my bad english.
> MariaDB version 10.5.18 is much slower than version 10.5.16 in
> string-manipulation (CONCAT).
Are you hit by MDEV-29988?
> In version 10.5.16 my code in the bottom needs for 800 records in
> tmp_tartikel_live 1-2 seconds.
> In version 10.5.18 my code needs for 800 records in tmp_tartikel_live 20-30
> seconds.
> In version 10.5.16 my code needs for 26000 records in tmp_tartikel_live 5-6
> minutes. It is ok.
> In version 10.5.18 my code needs for 26000 records in tmp_tartikel_live more
> than 2 hours and
> was terminating by the system and was not ready.
> The execution-time glows much more than linear.
> The calling script is internal for maintenance-work at night.
> The purpose of this code is to build our search-tables in MySQL (concordance).
> The code must work for strings with special characters in the coding-systems
> html (), ansi and utf-8.
> In german and france we have the special characters:
>
>
>
>
>
> and so on.
>
> I have found other users with performance-problems in MariaDB version
> 10.5.18, and they also use CONCAT:
>
> https://dba.stackexchange.com/questions/284073/query-performance-drop-after-upgrade-to-mariadb-10-5-group-concat-join
>
> My code is the following:
> /*#JODY_20221010
> Die Datenbank muss fuer diesen Code auf Kollektion=latin1_swedish_ci
> eingestellt sein.
> ALTER DATABASE d03a5b1c COLLATE latin1_swedish_ci;
> Das CHARACTER SET scheint nicht so wichtig zu sein.
> */
>
> /*
> #JODY_20211228 (ACHTUNG): Diese Datei muss ASCII-Codiert sein (nicht UTF8)
> Funktion zum Loeschen von HTML-Tags. Kann nur vom browser aus
> installiert werden.
> * /
> DROP PROCEDURE IF EXISTS mysql_log;*/
> DROP FUNCTION IF EXISTS mysql_striptags;
> DROP FUNCTION IF EXISTS mysql_replace_utf8_sonderzeichen;
> DROP FUNCTION IF EXISTS mysql_replace_single_char;
> DROP FUNCTION IF EXISTS mysql_replace_char;
> DROP FUNCTION IF EXISTS mysql_replace_umlaute;
> /*DROP FUNCTION IF EXISTS mysql_delete_fuellwoerter;*/
>
> DELIMITER $$
>
> /*CREATE PROCEDURE mysql_log(strText VARCHAR(255))
> BEGIN
> INSERT INTO debugout(cText) VALUES (strText);
> END$$*/
>
> CREATE FUNCTION mysql_striptags(strParam TEXT)
> RETURNS TEXT
> DETERMINISTIC
> BEGIN
> DECLARE str TEXT;
> DECLARE posOpen INT;
> DECLARE posClose INT;
>
> SET str = strParam;
> loop1: LOOP
> SET posOpen = LOCATE("<", str);
> SET posClose = LOCATE(">", str, posOpen);
> /*#JODY_20211228 Wenn posOpen 0 ist, dann ist posClose auch
> immer 0.*/
> IF posClose = 0 THEN
> LEAVE loop1;
> END IF;
> SET str = CONCAT(LEFT(str, posOpen - 1), " ", MID(str, posClose +
> 1));
> END LOOP loop1;
> RETURN str;
> END$$
>
> /*#JODY_20220201:
> Die Moeglichkeit zur URL-Erzeugung mit UTF8-Sonderzeichen besteht darin,
> dass ein Anwender Strings
> aus einem Eingabefeld in die Zwischenablage kopiert und dann im URL-Feld
> des Browsers einfuegt.
> Dann stehen in der URL z.B. fuer
> CONCAT(CHAR(195), CHAR(164))
> Das Problem ist also die Eingabe von Sonderzeichen im URL-Feld des
> Browsers.*/
> CREATE FUNCTION mysql_replace_utf8_sonderzeichen(strParam TEXT)
> RETURNS TEXT
> DETERMINISTIC
> BEGIN
> DECLARE str TEXT;
> DECLARE nPos INT;
> DECLARE nOrd INT;
> DECLARE strChar VARCHAR(2);
>
> SET str = strParam;
> SET nPos = 1;
> loop_for: LOOP
> SET nPos = LOCATE(CHAR(195), str, nPos); /*
> ACHTUNG (#JODY_20220201):
> Hier kommen auch Positionen auf ein einfaches a zurueck.
> Liegt an MySQL. Diese brauche
> ich hier zwar nicht. Aber der Code kann damit umgehen. Durch
> das LOCATE spare ich mir aber
> fuer die grosse Menge an Zeichen die Schleifendurchlaeufe.*/
> IF nPos = 0 THEN
> LEAVE loop_for;
> END IF;
> SET strChar = MID(str, nPos, 1);
> SET nPos = nPos + 1;
> IF ORD(strChar) != 195 THEN
> ITERATE loop_for;
> END IF;
> SET strChar = MID(str, nPos, 1);
> SET nOrd = ORD(strChar);
> IF nOrd >= 132 AND nOrd <= 188 THEN
> SET str = REPLACE(str, CONCAT(CHAR(195), strChar), CHAR(nOrd
> + 64));
> SET nPos = nPos + 1;
> END IF;
> END LOOP;
>
> RETURN str;
> END$$
>
> /*
> ACHTUNG (#JODY_20220120):
> Da strNewStr auch nur Blanks enthalten darf/kann, kann hier nicht mit
> CHAR(2) gearbeitet werden.
> Variablen vom Typ CHAR(x) waeren bei einem Wert von z.B. "
