Files search takes a long time with unified search #23835

jancborchardt · 2020-11-02T11:14:43Z

Depending on the amount of files, the file search component of unified search takes a long time to get results back. It’s the slowest of all – Talk, Mail and everything loads before. On our own instance, it takes roughly 40 seconds.

Also, there is no x in the input field during loading so it’s impossible to cancel the search – you have to wait for it to finish to start a different one. To fix this, we could replace the spinner with an x on hover/focus.

Gif for illustration, showing how it takes 40 seconds:

(This is very related to the direct filtering of the current folder, which also doesn’t work: #23432 )

cc @nextcloud/search

skjnldsv · 2020-11-02T11:16:31Z

Also, there is no x in the input field during loading so it’s impossible to cancel the search – you have to wait for it to finish to start a different one. To fix this, we could replace the spinner with an x on hover/focus.

Searching cancel other searches.
You can always change your query and it should trigger the search again

ChristophWurst · 2020-11-02T11:19:28Z

It's mainly slow because the files search implementation doesn't paginate. So you'd always build the full results list on the back-end before it's chopped into the individual pages. This doesn't scale, as you observed. Our instance just has a lot of files and shares, hence the slowness.

andreas-p · 2020-11-05T16:03:08Z

@ChristophWurst non-pagination is NOT the problem:

Pasting 152151 into the search term will yield a single result after ~4.7s (runtime taken from Firefox devtools).

Executing a query directly on the PostgreSQL 12.0 server (2.6e6 rows in oc_filecache):

SELECT * FROM oc_filecache WHERE name LIKE '%152151%: 0.5s
SELECT * FROM oc_filecache WHERE name ILIKE '%152151%: 1.1s

This makes NC file search at least 4 times slower than the database full table search.

If the search term is not entered by copy/paste, but typed in, things get much worse, since each character will trigger a new query on the server, consuming more resources (when typing fast, the final search request will take 16s).

@skjnldsv A new search does not cancel the running queries in the database backend.

skjnldsv · 2020-11-05T16:29:40Z

@skjnldsv A new search does not cancel the running queries in the database backend.

Right, it cancel the frontend request of course.

andreas-p · 2020-11-05T16:31:49Z

I enabled log_min_duration_statement=800 in the PostgreSQL Server, and found that each search will execute the same query four times, which explains the x4 observed above.

ChristophWurst · 2020-11-05T17:51:01Z

@ChristophWurst non-pagination is NOT the problem:

If there was pagination the query would include more WHERE clauses to scope the range. It would therefore help.

But yeah, ILIKE is expensive.

andreas-p · 2020-11-05T19:10:02Z

Not really, if the result set is small, or not at all when using window functions, since the time consuming part is the sequential scan, not the result set transfer.

For PostgreSQL, speed could be improved by not using name ILIKE :searchExpression (1.1s), but lower(name) ILIKE lower(:searchExpression) (0.8s) or even better lowercasedname LIKE lower(:searchExpression) (0.5s).

But there are fruits hanging much lower:

eliminating those 3 exceeding queries, there's something going awfully wrong here.
delaying search for some 300-500ms after the last keystroke, to prevent multiple zombie queries eating database performance.

More advanced:

split filesearch in two requests: First search the current directory only (my example has 4800 Files in the folder, <20ms), then the full scan. Quite often, only the current directory is of interest.

andreas-p · 2020-11-10T08:01:48Z

I found the reason why the database was hammered with the same query 4x for a single search. They correspond with four shares from the same user. These result in four MountPoints, having different different roots on the same physical storage (same numericId). Unfortunately, the filtering code is buried very deep in CacheWrapper, and each wrapper retrieves the full data from its Cache instance before filtering.
Hiding (parts of) the filtering from the View in separate Caches might be good programming practice in general, but is a real pain for big datasets. Can't see a way how to speed this up in a non-dirty way.

ohthehugemanatee · 2021-01-26T14:21:31Z

Suggest re-titling this issue in line with #24029 , since this is a regression in behavior from NC19. At best, we have lost the "fast search" capability. At worst, we've lost "search" alltogether.

My personal use case: updated to NC20 last night. Today, any search query will peg the mysql server and make nextcloud unresponsive. Having just performed a files:clean my oc_filecache table has 2057547 rows. It takes 2 seconds just to run the count query. :|

edit: it works... just very very slowly. > 10 seconds to search testing. So far 280s for large files for youtube. In mariadb processlist I see:

MariaDB [nextcloud]> show full processlist;
+-----+-------------+---------------------------------+-----------+---------+------+--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
| Id  | User        | Host                            | db        | Command | Time | State                    | Info                                                                                                                                                                                                                                                                                                                                                                                                                                                  | Progress |
+-----+-------------+---------------------------------+-----------+---------+------+--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
|   2 | system user |                                 | NULL      | Daemon  | NULL | InnoDB purge worker      | NULL                                                                                                                                                                                                                                                                                                                                                                                                                                                  |    0.000 |
|   1 | system user |                                 | NULL      | Daemon  | NULL | InnoDB purge coordinator | NULL                                                                                                                                                                                                                                                                                                                                                                                                                                                  |    0.000 |
|   3 | system user |                                 | NULL      | Daemon  | NULL | InnoDB purge worker      | NULL                                                                                                                                                                                                                                                                                                                                                                                                                                                  |    0.000 |
|   4 | system user |                                 | NULL      | Daemon  | NULL | InnoDB purge worker      | NULL                                                                                                                                                                                                                                                                                                                                                                                                                                                  |    0.000 |
|   5 | system user |                                 | NULL      | Daemon  | NULL | InnoDB shutdown handler  | NULL                                                                                                                                                                                                                                                                                                                                                                                                                                                  |    0.000 |
| 724 | nextcloud   | nextcloud.compose_default:52848 | nextcloud | Query   |  391 | Sending data             | SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 9) AND (`name`  COLLATE utf8mb4_general_ci LIKE '%test%')      |    0.000 |
| 734 | nextcloud   | nextcloud.compose_default:52950 | nextcloud | Query   |  391 | Sending data             | SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 9) AND (`name`  COLLATE utf8mb4_general_ci LIKE '%testing%')   |    0.000 |
| 746 | nextcloud   | nextcloud.compose_default:53052 | nextcloud | Query   |  390 | Sending data             | SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 9) AND (`name`  COLLATE utf8mb4_general_ci LIKE '%testing%')   |    0.000 |
| 760 | nextcloud   | nextcloud.compose_default:53164 | nextcloud | Query   |  320 | Sending data             | SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 9) AND (`name`  COLLATE utf8mb4_general_ci LIKE '%arge fil%')  |    0.000 |
| 769 | nextcloud   | nextcloud.compose_default:53284 | nextcloud | Query   |  320 | Sending data             | SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 9) AND (`name`  COLLATE utf8mb4_general_ci LIKE '%arge file%') |    0.000 |
| 771 | root        | localhost                       | nextcloud | Query   |    0 | Init                     | show full processlist                                                                                                                                                                                                                                                                                                                                                                                                                                 |    0.000 |
+-----+-------------+---------------------------------+-----------+---------+------+--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
11 rows in set (0.001 sec)

icewind1991 · 2021-01-26T20:33:38Z

#25136 should help with search performance, how much of a difference it makes will depend greatly on setup specifics.

jospoortvliet · 2021-01-27T17:15:18Z

A quick search just in the current folder, like the old search this - basically adding a search provider that is named 'current folder' would do the trick to at least give some results quickly, covering many cases, right? what do you think @jancborchardt

putt1ck · 2021-02-09T05:49:53Z

I think there's something more; if people get frustrated by getting no result they change the search, but the old search continues to put load on the DB. We saw a load of 60 on the DB server just from a few users trying to use search and getting frustrated with it. Why would the search continue if the user moves on (to another search or manually looking for the files)?

wiswedel · 2021-02-12T16:09:10Z

Why would the search continue if the user moves on (to another search or manually looking for the files)?

Good point. That then even applies to a search on the users and apps pages: Search for a user or an app, find quickly what you've been looking for (since those pages instantly narrow down), but have the unrelated unified search load remaining in the background.

putt1ck · 2021-03-10T12:11:22Z

We're having increased frustration levels with the search issue (big instance as in many files); is there anything we can do to patch this, either to improve performance back to NC19 levels or limit search to specific groups - even disable, unless that prevents user lookups for sharing.

putt1ck · 2021-03-10T13:37:59Z

NB is search much faster in NC21?

ChristophWurst · 2021-03-10T14:40:30Z

There were optimizations as far as I know, but most of the technical bottlenecks are yet to be improved.

ChristophWurst · 2021-03-10T19:01:53Z

Some improvements fresh out of the oven: #26049

andreas-p · 2021-03-10T19:10:19Z

Well that improvement is merely a drop in the ocean. It limits the amount of data being transferred (if not cancelled anyway by the next longer search term), but will not tackle the multitude of huge database queries.

ChristophWurst · 2021-03-11T07:26:38Z

Well, I tried to help and keep you updated.

andreas-p · 2021-03-11T08:13:46Z

@ChristophWurst updates are appreciated.
Are there ongoing efforts to fix the issue fundamentally, i.e. provide a file search that works and unified search that won't DoS the db server?

ChristophWurst · 2021-03-11T08:20:03Z

I can't tell because I don't work on those internals.

pjft · 2022-02-06T11:52:14Z

Subscribing here. I can confirm that search in 19 was almost instant, and now it takes dozens of seconds at times, which is suboptimal. I did think increasing MySQL memory and cache size would make a difference, but alas it didn't.

ohthehugemanatee · 2022-03-02T20:46:56Z

@gennaios if you can provide the SQL it will help a lot. I or another php-head can figure out how to work that into the existing PHP...

gennaios · 2022-03-04T04:51:59Z

@ohthehugemanatee I might very possibly be able to sometime though I may not be able to get to it for a little while.

If you or someone could provide the current SQL for record insertion and selection, I'd have an idea of the relevant needed columns and table structure.

SQLite likely could use an external content table. In such a case, one needs manaually manage: an additional insert into the FTS table, and with any change, first grab old value before change (such as rename), provide such values for a delete statement, then insert new. Or for delete, merely grab value from file table and delete from FTS before deleteing from file. MySQL and PostgreSQL I believe are easier.

Concerning other areas where FTS could be used, I recall some issue for contacts where one ended up patching and implementing himself. One maybe could track that down and possibly merge.

ustuzhanin · 2022-03-31T19:31:14Z

I'll just leave this here..
Before

Query time over 1h

Add:
create index t_oc_filecache_storage_mtime_name on oc_filecache (storage,mtime DESC,name);

After:

Query time ~3s

Using index on mtime with %% on name - very bad idea.
In order to prevent this, it is worth change ORDER BY mtime to ORDER BY mtime+0

glorenzutti · 2022-03-31T19:36:55Z

I'll just leave this here.. Before Query time over 1h

Add: create index t_oc_filecache_storage_mtime_name on oc_filecache (storage,mtime DESC,name);

After: Query time ~3s

Using index on mtime with %% on name - very bad idea. In order to prevent this, it is worth change ORDER BY mtime to ORDER BY mtime+0

Hi there! Nextcloud version?

ustuzhanin · 2022-03-31T19:37:56Z

21.0.9
But i`m check code. Didn't see any changes

glorenzutti · 2022-03-31T19:42:11Z

Tnxs! Im gonna check later.
Maybe there was some change on the schema.
Im on 23.0.2.

ustuzhanin · 2022-03-31T19:43:44Z

Tnxs! Im gonna check later. Maybe there was some change on the schema. Im on 23.0.2.

| oc_filecache | CREATE TABLE `oc_filecache` (
  `fileid` bigint NOT NULL AUTO_INCREMENT,
  `storage` bigint NOT NULL DEFAULT '0',
  `path` varchar(4000) COLLATE utf8mb4_bin DEFAULT NULL,
  `path_hash` varchar(32) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `parent` bigint NOT NULL DEFAULT '0',
  `name` varchar(250) COLLATE utf8mb4_bin DEFAULT NULL,
  `mimetype` bigint NOT NULL DEFAULT '0',
  `mimepart` bigint NOT NULL DEFAULT '0',
  `size` bigint NOT NULL DEFAULT '0',
  `mtime` bigint NOT NULL DEFAULT '0',
  `storage_mtime` bigint NOT NULL DEFAULT '0',
  `encrypted` int NOT NULL DEFAULT '0',
  `unencrypted_size` bigint NOT NULL DEFAULT '0',
  `etag` varchar(40) COLLATE utf8mb4_bin DEFAULT NULL,
  `permissions` int DEFAULT '0',
  `checksum` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`fileid`),
  UNIQUE KEY `fs_storage_path_hash` (`storage`,`path_hash`),
  KEY `fs_parent_name_hash` (`parent`,`name`),
  KEY `fs_storage_mimetype` (`storage`,`mimetype`),
  KEY `fs_storage_mimepart` (`storage`,`mimepart`),
  KEY `fs_storage_size` (`storage`,`size`,`fileid`),
  KEY `fs_mtime` (`mtime`),
  KEY `fs_size` (`size`),
  KEY `fs_storage_path_prefix` (`storage`,`path`(64)),
  KEY `fs_id_storage_size` (`fileid`,`storage`,`size`),
  KEY `t_oc_filecache_storage_path_name_mtime` (`storage`,`mtime` DESC,`name`)
) ENGINE=InnoDB AUTO_INCREMENT=188162449 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED |

In my schema

glorenzutti · 2022-03-31T19:50:16Z

This is the diff with my running version.

$ diff my_filecache git_filecache
25d24
< KEY fs_storage (storage) USING BTREE,
26a26

KEY fs_storage_path_prefix (storage,path(64)),
28,29c28,29
< KEY fs_storage_path_prefix (storage,path(64))
< ) ENGINE=InnoDB AUTO_INCREMENT=19907648 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED |

KEY t_oc_filecache_storage_path_name_mtime (storage,mtime DESC,name)
) ENGINE=InnoDB AUTO_INCREMENT=188162449 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED |

tacruc · 2022-10-04T08:42:57Z

Hi I'm wondering if my Issue is related. I'm running Nextcloud 25rc2 and I have this querry:

SELECT `file`.`fileid`, `storage`, `path`, `path_hash`, `file`.`parent`, `file`.`name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `unencrypted_size` FROM `oc_filecache` `file` LEFT JOIN `oc_vcategory_to_object` `tagmap` ON `file`.`fileid` = `tagmap`.`objid` LEFT JOIN `oc_systemtag_object_mapping` `systemtagmap` ON (`file`.`fileid` = `systemtagmap`.`objectid`) AND (`systemtagmap`.`objecttype` = 'files') LEFT JOIN `oc_vcategory` `tag` ON (`tagmap`.`type` = `tag`.`type`) AND (`tagmap`.`categoryid` = `tag`.`id`) AND (`tag`.`type` = 'files') AND (`tag`.`uid` = 'arne') LEFT JOIN `oc_systemtag` `systemtag` ON (`systemtag`.`id` = `systemtagmap`.`systemtagid`) AND (`systemtag`.`visibility` = '1') WHERE ((`tag`.`category` COLLATE utf8mb4_general_ci LIKE '%icons.png%') OR (`systemtag`.`name` COLLATE utf8mb4_general_ci LIKE '%icons.png%')) AND (((`storage` = 3) AND ((`path` = 'files') OR (`path` LIKE 'files/%'))) OR (`storage` = 176) OR (`storage` = 203) OR (`storage` = 214) OR (`storage` = 227) OR (`storage` = 228) OR ((`storage` = 76) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 89) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 89) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 4) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 4) AND ((`path_hash` = '96e07e5386d9345589a915047cfce3a8') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 4) AND ((`path_hash` = '5528724ec2bedea7c8542d53b11f0016') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 76) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 161) AND (`path_hash` = '58e1c3bca52a6832e842f73392a5bac4')) OR ((`storage` = 8) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED'29aba51cd209f7c261be0b4df9b13ba5') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 4) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 8) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 8) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 5) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path_hash` = '0c8570a357b65c15abc67651c1ec72bd') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 9) AND ((`path` = 'PATHREPLACED') OR (`path` LIKE 'PATHREPLACED/%'))) OR ((`storage` = 8) AND (`path_hash` = 'b03706e617445929129e92c4db9971d9'))) ORDER BY `mtime` + '0' desc LIMIT 5

And 5 other like this running for 19 hours now. Somewhere yesterday I searched for "icons.png".

szaimen · 2022-11-26T13:54:53Z

Hi, please update to at least 23.0.12 and report back if it fixes the issue. Thank you!

pjft · 2022-11-26T14:50:37Z

I think this is good on 25 already.

szaimen · 2022-11-26T14:51:57Z

Thanks for testing!

pjft · 2022-11-26T14:55:38Z

For what it's worth, I think it was also good on 24, as I was running it for a few weeks before 25 was stable.

Thanks for checking.

gennaios · 2022-11-27T00:36:44Z

For those that have thousands of files and potentially many search results with each search, displaying five at a time is not an ideal solution. Does such merely mask the issue?

pjft · 2022-11-27T00:59:19Z

I agree with the comment about the UI and only showing five results at a time, but it is unrelated to the performance issues or fixes. The performance issues were there when the UI was already only showing 5 results at a time, unless I'm mistaken.

Nothing changed there. It's just the performance that improved.

Edit: still, I'd be happy with a way to open search results in a proper, long list format. Like it used to be before it got reduced to showing results in the search panel alone.

pjrobertson · 2023-02-17T11:52:38Z

Edit: still, I'd be happy with a way to open search results in a proper, long list format. Like it used to be before it got reduced to showing results in the search panel alone.

I second this. The current small search panel is not very user friendly. It's small and doesn't show the full names/file paths of files when you search, and is clunky to scroll through. Furthermore, if you type a search then hit enter ↩, it'll automatically open the first result, which is counter-intuitive.

It'd be great to have a full search page available. Gmail gives a good example of good search usability. Showing a popup window initially, and then another window if you hit enter.

glorenzutti · 2023-02-17T21:22:09Z

Can I second this too ? second seconder? or a thirder?

The UI has some room for improvement.

jancborchardt added bug 1. to develop Accepted and waiting to be taken care of feature: search labels Nov 2, 2020

This was referenced Nov 10, 2020

Regression in NC20: no usable file search any more #24029

Closed

Unified search - search in current app by default #24056

Open

wiswedel added regression high labels Jan 26, 2021

wiswedel added 20-feedback labels Mar 11, 2021

blizzz modified the milestones: Nextcloud 24, Nextcloud 25 Apr 21, 2022

blizzz modified the milestones: Nextcloud 25, Nextcloud 26 Oct 19, 2022

szaimen added needs info 0. Needs triage Pending check for reproducibility or if it fits our roadmap and removed 1. to develop Accepted and waiting to be taken care of labels Nov 26, 2022

szaimen closed this as completed Nov 26, 2022

XueSheng-GIT mentioned this issue Dec 14, 2022

[Bug]: File and tag search slow if a lot of shares present #35776

Closed

9 tasks

kesselb mentioned this issue May 15, 2023

[Bug]: File Search poor performance with lots of files because of index workaround #38243

Open

9 tasks

acazenave added this to POC - Upstream ticket followup Aug 30, 2024

acazenave moved this to Todo in POC - Upstream ticket followup Aug 30, 2024

Files search takes a long time with unified search #23835

Files search takes a long time with unified search #23835

Comments

jancborchardt commented Nov 2, 2020

skjnldsv commented Nov 2, 2020

ChristophWurst commented Nov 2, 2020

andreas-p commented Nov 5, 2020

skjnldsv commented Nov 5, 2020

andreas-p commented Nov 5, 2020

ChristophWurst commented Nov 5, 2020

andreas-p commented Nov 5, 2020

andreas-p commented Nov 10, 2020 • edited Loading

ohthehugemanatee commented Jan 26, 2021 • edited Loading

icewind1991 commented Jan 26, 2021

jospoortvliet commented Jan 27, 2021

putt1ck commented Feb 9, 2021

wiswedel commented Feb 12, 2021

putt1ck commented Mar 10, 2021

putt1ck commented Mar 10, 2021

ChristophWurst commented Mar 10, 2021

ChristophWurst commented Mar 10, 2021

andreas-p commented Mar 10, 2021 • edited Loading

ChristophWurst commented Mar 11, 2021

andreas-p commented Mar 11, 2021

ChristophWurst commented Mar 11, 2021

pjft commented Feb 6, 2022

ohthehugemanatee commented Mar 2, 2022

gennaios commented Mar 4, 2022 • edited Loading

ustuzhanin commented Mar 31, 2022

glorenzutti commented Mar 31, 2022

ustuzhanin commented Mar 31, 2022

glorenzutti commented Mar 31, 2022

ustuzhanin commented Mar 31, 2022

glorenzutti commented Mar 31, 2022

tacruc commented Oct 4, 2022 • edited Loading

szaimen commented Nov 26, 2022

pjft commented Nov 26, 2022

szaimen commented Nov 26, 2022

pjft commented Nov 26, 2022

gennaios commented Nov 27, 2022

pjft commented Nov 27, 2022 • edited Loading

pjrobertson commented Feb 17, 2023

glorenzutti commented Feb 17, 2023

andreas-p commented Nov 10, 2020 •

edited

Loading

ohthehugemanatee commented Jan 26, 2021 •

edited

Loading

andreas-p commented Mar 10, 2021 •

edited

Loading

gennaios commented Mar 4, 2022 •

edited

Loading

tacruc commented Oct 4, 2022 •

edited

Loading

pjft commented Nov 27, 2022 •

edited

Loading