Possibly expensive SQL Query on determining files to process #144

kriegerse · 2024-10-02T20:18:19Z

Description

Hey it's me again :-D

I've recognized a high load on my Maria DB Instance. It took me a while to identify what cause the load but the MariaDB slow log is very clear about the SQL Statement and I suspect to trace it down to the GData VaaS App.

It looks like the GData VaaS makes an uncomfortable SQL Query to the Database not performing well.

Reproduce

Install Nextcloud
Install gdatavaas App
Possibly have a lot of files + folder in your nextcloud and/or oc_filecache table - I count:
- ~293491 in my nc/oc data dir (overall)
  - ~27351 in my (sinlge) userdir
  - ~265999 in my appdata folder (including previews)
- ~ 349134 in oc_filecache table
Hardware simple NAS with:
- Intel(R) Celeron(R) J4105 CPU @ 1.50GHz
- 32GB RAM

For sure no enterprise grade hardware but also no numbers of files like enterprises have.

Log(s) & Analysis

MariaDB Slow Log - I see a couple of them in my slow.log but average run of the query is always around ~800 seconds (~14 Minutes)

# Time: 241002 18:45:26
# User@Host: oc_XXXXXX[oc_XXXXXX] @  [XXX.XXX.XXX.XXX]
# Thread_id: 32250  Schema: XXX-owncloud  QC_hit: No
# Query_time: 908.723772  Lock_time: 0.000139  Rows_sent: 10000  Rows_examined: 505241
# Rows_affected: 0  Bytes_sent: 120089
SET timestamp=1727894726;
SELECT `f`.`fileid` FROM `oc_filecache` `f` LEFT JOIN `oc_systemtag_object_mapping` `o` ON `f`.`fileid` = CAST(o.objectid AS UNSIGNED) LEFT JOIN `oc_mimetypes` `m` ON `f`.`mimetype` = `m`.`id` WHERE ((`o`.`systemtagid` NOT IN (248, 249, 251, 250, 252)) OR (`o`.`systemtagid` IS NULL)) AND (`m`.`mimetype` NOT LIKE '%unix-directory%') AND ((`f`.`path` LIKE 'files/%') OR (`f`.`path` LIKE '__groupfolders/%')) ORDER BY `f`.`fileid` DESC LIMIT 10000;

MariaDB - Explain: about the statement

MariaDB [XXX-owncloud]> EXPLAIN SELECT `f`.`fileid` FROM `oc_filecache` `f` LEFT JOIN `oc_systemtag_object_mapping` `o` ON `f`.`fileid` = CAST(o.objectid AS UNSIGNED) LEFT JOIN `oc_mimetypes` `m` ON `f`.`mimetype` = `m`.`id` WHERE ((`o`.`systemtagid` NOT IN (248, 249, 251, 250, 252)) OR (`o`.`systemtagid` IS NULL)) AND (`m`.`mimetype` NOT LIKE '%unix-directory%') AND ((`f`.`path` LIKE 'files/%') OR (`f`.`path` LIKE '__groupfolders/%')) ORDER BY `f`.`fileid` DESC LIMIT 10000;
+------+-------------+-------+--------+---------------+---------+---------+----------------------------+--------+--------------------------------------------------------------+
| id   | select_type | table | type   | possible_keys | key     | key_len | ref                        | rows   | Extra                                                        |
+------+-------------+-------+--------+---------------+---------+---------+----------------------------+--------+--------------------------------------------------------------+
|    1 | SIMPLE      | f     | ALL    | NULL          | NULL    | NULL    | NULL                       | 118467 | Using where; Using temporary; Using filesort                 |
|    1 | SIMPLE      | m     | eq_ref | PRIMARY       | PRIMARY | 8       | XXX-owncloud.f.mimetype    | 1      | Using where                                                  |
|    1 | SIMPLE      | o     | index  | NULL          | PRIMARY | 524     | NULL                       | 7758   | Using where; Using index; Using join buffer (flat, BNL join) |
+------+-------------+-------+--------+---------------+---------+---------+----------------------------+--------+--------------------------------------------------------------+
3 rows in set (0.001 sec)

Not an MariaDB/SQL Expert but it looks like for the first part of the query with oc_filecache table no index can be utilized and endup in a expensive full table scan

Simple Select of first oc_filecache is able to utilize index

MariaDB [XXX-owncloud]> EXPLAIN SELECT `f`.`fileid` FROM `oc_filecache` `f` ;
+------+-------------+-------+-------+---------------+----------+---------+------+--------+-------------+
| id   | select_type | table | type  | possible_keys | key      | key_len | ref  | rows   | Extra       |
+------+-------------+-------+-------+---------------+----------+---------+------+--------+-------------+
|    1 | SIMPLE      | f     | index | NULL          | fs_mtime | 8       | NULL | 118467 | Using index |
+------+-------------+-------+-------+---------------+----------+---------+------+--------+-------------+
1 row in set (0.000 sec)

The tag IDs (248, 249, 251, 250, 252) seems to belong to GData VaaS to manage states

MariaDB [XXX-owncloud]> SELECT * FROM `oc_systemtag` WHERE `id` IN (248, 249, 251, 250, 252) ORDER BY id;
+-----+------------+------------+----------+
| id  | name       | visibility | editable |
+-----+------------+------------+----------+
| 248 | Unscanned  |          1 |        0 |
| 249 | Malicious  |          1 |        0 |
| 250 | Pup        |          1 |        0 |
| 251 | Clean      |          1 |        0 |
| 252 | Won't scan |          1 |        0 |
+-----+------------+------------+----------+
5 rows in set (0.001 sec)

Database Stats

Some statistic data might help for the issue

Count Rows on oc_filecache (f)

MariaDB [XXX-owncloud]> SELECT COUNT(`f`.`fileid`) FROM `oc_filecache` `f` ;
+---------------------+
| COUNT(`f`.`fileid`) |
+---------------------+
|              349134 |
+---------------------+
1 row in set (0.121 sec)

Count Rows on oc_systemtag_object_mapping (o)

MariaDB [XXX-owncloud]> SELECT COUNT(*) FROM `oc_systemtag_object_mapping`  ;
+----------+
| COUNT(*) |
+----------+
|   119045 |
+----------+

Count Rows on oc_mimetypes (m)

MariaDB [XXX-owncloud]> SELECT COUNT(*) FROM `oc_mimetypes`  ;
+----------+
| COUNT(*) |
+----------+
|      184 |
+----------+
1 row in set (0.000 sec)

Available Indices

oc_filecache

MariaDB [XXX-owncloud]> show index from oc_filecache;
+--------------+------------+--------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| Table        | Non_unique | Key_name                 | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Ignored |
+--------------+------------+--------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| oc_filecache |          0 | PRIMARY                  |            1 | fileid      | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          0 | fs_storage_path_hash     |            1 | storage     | A         |          12 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          0 | fs_storage_path_hash     |            2 | path_hash   | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_parent_name_hash      |            1 | parent      | A         |       31323 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_parent_name_hash      |            2 | name        | A         |      118455 |     NULL | NULL   | YES  | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_mimetype      |            1 | storage     | A         |          12 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_mimetype      |            2 | mimetype    | A         |         250 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_mimepart      |            1 | storage     | A         |          12 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_mimepart      |            2 | mimepart    | A         |          38 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_size          |            1 | storage     | A         |          12 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_size          |            2 | size        | A         |       70369 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_size          |            3 | fileid      | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_mtime                 |            1 | mtime       | A         |       42210 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_size                  |            1 | size        | A         |       35679 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_id_storage_size       |            1 | fileid      | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_id_storage_size       |            2 | storage     | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_id_storage_size       |            3 | size        | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_parent                |            1 | parent      | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | memories_parent_mimetype |            1 | parent      | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | memories_parent_mimetype |            2 | mimetype    | A         |      118467 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | memories_name_hash       |            1 | name        | A         |       29616 |     NULL | NULL   | YES  | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_path_prefix   |            1 | storage     | A         |           9 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_filecache |          1 | fs_storage_path_prefix   |            2 | path        | A         |      118467 |       64 | NULL   | YES  | BTREE      |         |               | NO      |
+--------------+------------+--------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
23 rows in set (0.001 sec)

As other apps (memories) maintain there own indices, this might be also a solution for GData VaaS - if some is missing/can not utilized

oc_mimetypes

MariaDB [XXX-owncloud]> show index from oc_mimetypes;
+--------------+------------+-------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| Table        | Non_unique | Key_name          | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Ignored |
+--------------+------------+-------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| oc_mimetypes |          0 | PRIMARY           |            1 | id          | A         |         171 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_mimetypes |          0 | mimetype_id_index |            1 | mimetype    | A         |         171 |     NULL | NULL   |      | BTREE      |         |               | NO      |
+--------------+------------+-------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
2 rows in set (0.001 sec)

oc_systemtag_object_mapping

MariaDB [XXX-owncloud]> show index from oc_systemtag_object_mapping;
+-----------------------------+------------+---------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| Table                       | Non_unique | Key_name            | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Ignored |
+-----------------------------+------------+---------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| oc_systemtag_object_mapping |          0 | PRIMARY             |            1 | objecttype  | A         |           1 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          0 | PRIMARY             |            2 | objectid    | A         |        7750 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          0 | PRIMARY             |            3 | systemtagid | A         |        7758 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          1 | systag_by_tagid     |            1 | systemtagid | A         |          19 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          1 | systag_by_tagid     |            2 | objecttype  | A         |          29 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          1 | memories_type_tagid |            1 | objecttype  | A         |           0 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          1 | memories_type_tagid |            2 | systemtagid | A         |          17 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| oc_systemtag_object_mapping |          1 | systag_by_objectid  |            1 | objectid    | A         |        2586 |     NULL | NULL   |      | BTREE      |         |               | NO      |
+-----------------------------+------------+---------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
8 rows in set (0.000 sec)

Expected behavior

GData VaaS performs well with SQL queries - the SQL Statement mentioned shouldn't run minutes also with respect to enterprise grade instances

Versions

Nextcloud Hub 8 [29.0.7]
Gdatavaas [29.4.3]
MariaDB [10.11.9]

Sorry for this possibly hard nut

The text was updated successfully, but these errors were encountered:

lennartdohmann · 2024-10-02T21:03:56Z

Hi, welcome back :D Thanks for the detailed description and all the information. This will certainly help a lot. In any case, I agree that the app should be more performant than it seems to be now, even with so many files. Due to a public holiday tomorrow and the following bridge day (for most people), this will probably have to wait a few days. But I'll get straight to have a look on it on Monday.

kriegerse · 2024-10-02T21:18:35Z

You're Welcome

If you need some "performance tests" I'm willing to run some SELECT statements against my DB Instance providing results.

Enjoy your days off :-)

kriegerse · 2024-10-09T13:05:37Z

Hey - I did some further experiments and analysis.

It looks like the problematic part of the query is the LEFT JOIN with CAST STATEMENT. MariaDB can not utilize the indexes therefor.

But when I create corresponding data types and indexes in the relevant oc_systemtag_object_mapping table the query can perform well.

ALTER TABLE with objectid_int column

ALTER TABLE oc_systemtag_object_mapping
ADD COLUMN objectid_int BIGINT(20) UNSIGNED GENERATED ALWAYS AS (CAST(objectid AS UNSIGNED)) STORED;

CREATE AN INDEX on objectid_int

CREATE INDEX idx_objectid_int ON oc_systemtag_object_mapping(objectid_int);

Change the query to make use of new objectid_int column

EXPLAIN
SELECT `f`.`fileid` FROM `oc_filecache` `f` 
LEFT JOIN `oc_systemtag_object_mapping` `o` ON `f`.`fileid` = `o`.`objectid_int` 
LEFT JOIN `oc_mimetypes` `m` ON `f`.`mimetype` = `m`.`id` 
WHERE 
    ((`o`.`systemtagid` NOT IN (248, 249, 251, 250, 252)) OR (`o`.`systemtagid` IS NULL)) 
    AND (`m`.`mimetype` NOT LIKE '%unix-directory%') 
    AND ((`f`.`path` LIKE 'files/%') OR (`f`.`path` LIKE '__groupfolders/%')) 
ORDER BY `f`.`fileid` DESC 
LIMIT 10000;

+------+-------------+-------+--------+------------------+------------------+---------+----------------------------+------+--------------------------+
| id   | select_type | table | type   | possible_keys    | key              | key_len | ref                        | rows | Extra                    |
+------+-------------+-------+--------+------------------+------------------+---------+----------------------------+------+--------------------------+
|    1 | SIMPLE      | f     | index  | NULL             | PRIMARY          | 8       | NULL                       | 5000 | Using where              |
|    1 | SIMPLE      | m     | eq_ref | PRIMARY          | PRIMARY          | 8       | XXX-owncloud.f.mimetype | 1    | Using where              |
|    1 | SIMPLE      | o     | ref    | idx_objectid_int | idx_objectid_int | 9       | XXX-owncloud.f.fileid   | 2    | Using where; Using index |
+------+-------------+-------+--------+------------------+------------------+---------+----------------------------+------+--------------------------+
3 rows in set (0.001 sec)

Executing the query will delivers results in below 1 second

[...]
| 3638044 |
| 3638023 |
| 3638023 |
| 3638023 |
+---------+
10000 rows in set (0.066 sec)

Problematic with this is that I've touched the nextcloud standard which could be problematic on updates/upgrade - maybe something similar can be achieved with an own GData VaaS mapping table exclusively track the files processed.

Btw ... As you see on the result, the query above gives back the fileid multiple times, when the file has multiple tags not belonging to GData VaaS. This is true for my query as for the problematic one.

I therefor further "optimized" mine with SELECT DISTINCT

SELECT DISTINCT `f`.`fileid` FROM `oc_filecache` `f` 
LEFT JOIN `oc_systemtag_object_mapping` `o` ON `f`.`fileid` = `o`.`objectid_int` 
LEFT JOIN `oc_mimetypes` `m` ON `f`.`mimetype` = `m`.`id` 
WHERE 
    ((`o`.`systemtagid` NOT IN (248, 249, 251, 250, 252)) OR (`o`.`systemtagid` IS NULL)) 
    AND (`m`.`mimetype` NOT LIKE '%unix-directory%') 
    AND ((`f`.`path` LIKE 'files/%') OR (`f`.`path` LIKE '__groupfolders/%')) 
ORDER BY `f`.`fileid` DESC 
LIMIT 10000;

RESULTING: 
[...]
| 3270470 |
| 3270469 |
| 3270468 |
| 3270467 |
+---------+
10000 rows in set (0.456 sec)

pstadermann · 2024-10-16T07:37:39Z

It appears that we don't have to add new columns or indices. The current query is not filtering on oc_systemtag_object_mapping.objecttype. The composite index (objecttype, objectid, systemtagid) is not used.

If you find the time, it would be great to know, if the new query is faster than 1s on your system.

We will release the fix in the coming days.

Test data

SELECT COUNT(*) FROM oc_filecache;
200470

SELECT COUNT(*) FROM oc_systemtag_object_mapping;
200044

Current query

SELECT
    `f`.`fileid`
FROM
    `oc_filecache` `f`
    LEFT JOIN `oc_systemtag_object_mapping` `o` ON `f`.`fileid` = CAST(o.objectid AS UNSIGNED)
    LEFT JOIN `oc_mimetypes` `m` ON `f`.`mimetype` = `m`.`id`
WHERE
    (
        (
            `o`.`systemtagid` NOT IN (248, 249, 251, 250, 252)
        )
        OR (`o`.`systemtagid` IS NULL)
    )
    AND (`m`.`mimetype` NOT LIKE '%unix-directory%')
    AND (
        (`f`.`path` LIKE 'files/%')
        OR (`f`.`path` LIKE '__groupfolders/%')
    )
ORDER BY
    `f`.`fileid` DESC
LIMIT
    10000;

Runtime: Aborted after 18min

EXPLAIN:

id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	f	ALL	null	null	null	null	184619	100	Using where; Using temporary; Using filesort
1	SIMPLE	m	eq_ref	PRIMARY	PRIMARY	8	nextcloud.f.mimetype	1	100	Using where
1	SIMPLE	o	index	null	PRIMARY	524	null	191839	100	Using where; Using index; Using join buffer (flat, BNL join)

New query

SELECT
    `f`.`fileid`
FROM
    `oc_filecache` `f`
    LEFT JOIN `oc_systemtag_object_mapping` `o` ON `f`.`fileid` = CAST(o.objectid AS UNSIGNED)
    LEFT JOIN `oc_mimetypes` `m` ON `f`.`mimetype` = `m`.`id`
WHERE
    (
        (
            `o`.`systemtagid` NOT IN (248, 249, 251, 250, 252)
        )
        OR (`o`.`systemtagid` IS NULL)
    )
    AND (o.objecttype = 'files')
    AND (`m`.`mimetype` NOT LIKE '%unix-directory%')
    AND (
        (`f`.`path` LIKE 'files/%')
        OR (`f`.`path` LIKE '__groupfolders/%')
    )
ORDER BY
    `f`.`fileid` DESC
LIMIT
    10000;

Runtime: 800ms

EXPLAIN:

id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	o	ref	PRIMARY,systag_by_tagid	PRIMARY	258	const	95919	50	Using where; Using index; Using temporary; Using filesort
1	SIMPLE	f	eq_ref	PRIMARY,fs_id_storage_size	PRIMARY	8	func	1	100	Using where
1	SIMPLE	m	eq_ref	PRIMARY	PRIMARY	8	nextcloud.f.mimetype	1	100	Using where

Optimize getFileIdsWithoutTags, getFileIdsWithTags

Fix getFileIdsWithoutTags

pstadermann · 2024-10-16T13:46:16Z

Still got some issues. The SQL query is not correct. Will update once I get it running.

Cast fileid to objectid and use the index

String type for all supported DBs

Possibly expensive SQL Query on determining files to process #144 Optimize getFileIdsWithoutTags, getFileIdsWithTags --------- Co-authored-by: Philip Stadermann <[email protected]> Co-authored-by: Lennart Dohmann <[email protected]>

lennartdohmann · 2024-10-17T13:44:40Z

Should be solved with e266783 in the next release.

Fix cast for MySQL

Possibly expensive SQL Query on determining files to process #144 Optimize getFileIdsWithoutTags, getFileIdsWithTags --------- Co-authored-by: Philip Stadermann <[email protected]> Co-authored-by: Lennart Dohmann <[email protected]> (cherry picked from commit e266783)

Fix cast for MySQL (cherry picked from commit 7d8ae58)

Possibly expensive SQL Query on determining files to process #144 Optimize getFileIdsWithoutTags, getFileIdsWithTags --------- Co-authored-by: Philip Stadermann <[email protected]> Co-authored-by: Lennart Dohmann <[email protected]> (cherry picked from commit e266783)

Fix cast for MySQL (cherry picked from commit 7d8ae58)

kriegerse · 2024-10-26T18:34:12Z

Can confirm the fix - didn't see any entries anymore in the slow log for the problematic query after latest release.
again - thanks for fixing 👍

lennartdohmann self-assigned this Oct 2, 2024

lennartdohmann added the enhancement New feature or request label Oct 2, 2024

lennartdohmann pinned this issue Oct 2, 2024

kriegerse mentioned this issue Oct 9, 2024

Files not scanned on update or change #147

Closed

pstadermann pushed a commit that referenced this issue Oct 16, 2024

Possibly expensive SQL Query on determining files to process #144

7343efa

Optimize getFileIdsWithoutTags, getFileIdsWithTags

pstadermann pushed a commit that referenced this issue Oct 16, 2024

Possibly expensive SQL Query on determining files to process #144

e80973d

Optimize getFileIdsWithoutTags, getFileIdsWithTags

pstadermann pushed a commit that referenced this issue Oct 16, 2024

Possibly expensive SQL Query on determining files to process #144

e5eceab

Fix getFileIdsWithoutTags

pstadermann pushed a commit that referenced this issue Oct 16, 2024

Possibly expensive SQL Query on determining files to process #144

2550edb

Cast fileid to objectid and use the index

pstadermann pushed a commit that referenced this issue Oct 17, 2024

Possibly expensive SQL Query on determining files to process #144

24d5e72

String type for all supported DBs

lennartdohmann closed this as completed Oct 17, 2024

pstadermann pushed a commit that referenced this issue Oct 18, 2024

Possibly expensive SQL Query on determining files to process #144

7d8ae58

Fix cast for MySQL

lennartdohmann pushed a commit that referenced this issue Oct 22, 2024

Possibly expensive SQL Query on determining files to process #144

a9d2c2e

Fix cast for MySQL (cherry picked from commit 7d8ae58)

lennartdohmann pushed a commit that referenced this issue Oct 23, 2024

Possibly expensive SQL Query on determining files to process #144

db353f9

Fix cast for MySQL (cherry picked from commit 7d8ae58)

lennartdohmann unpinned this issue Oct 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Possibly expensive SQL Query on determining files to process #144

Possibly expensive SQL Query on determining files to process #144

kriegerse commented Oct 2, 2024 •

edited

Loading

lennartdohmann commented Oct 2, 2024

kriegerse commented Oct 2, 2024

kriegerse commented Oct 9, 2024

pstadermann commented Oct 16, 2024

pstadermann commented Oct 16, 2024

lennartdohmann commented Oct 17, 2024

kriegerse commented Oct 26, 2024

Possibly expensive SQL Query on determining files to process #144

Possibly expensive SQL Query on determining files to process #144

Comments

kriegerse commented Oct 2, 2024 • edited Loading

Description

Reproduce

Log(s) & Analysis

Database Stats

Available Indices

Expected behavior

Versions

lennartdohmann commented Oct 2, 2024

kriegerse commented Oct 2, 2024

kriegerse commented Oct 9, 2024

pstadermann commented Oct 16, 2024

Test data

Current query

New query

pstadermann commented Oct 16, 2024

lennartdohmann commented Oct 17, 2024

kriegerse commented Oct 26, 2024

kriegerse commented Oct 2, 2024 •

edited

Loading