https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35361
--- Comment #8 from Andreas Jonsson <[email protected]> --- It is not hypothetical. If you find an invoice under Acquisitions -> Invoices and then "Go to receipt page" (i.e., acqui/parcel.pl) you will find a table with open orders. If you type anything into the search filter, the above will be the sql-query generated. Since there are LEFT JOIN clauses applied after the limit have been applied, and several of those joins have the potential to multiply the number of result lines that are produced, the number of matched lines can explode. The problem is that all lines are loaded into a perl-process that filters out duplicates. This perl-filtering consumes heaps of memory and takes several minutes to perform. Since it is an automatic search performed by typing in the box there will typically be multiple such search requests issued. This makes the system unresponsive and likely triggers the oom killer. The Libraries in question is using a work flow for their acquisitions where orders are often left opened. Over time there will be many open orders. It starts to become problematic at about 20,000 open orders. Of course, this should not be a problem, because the request should have been limited to return at most 20 rows. DBIx is fundamentally flawed, and I think it would be a good idea to write our own sql-queries and our own code for generating sql queries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
