https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 --- Comment #82 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Hi all, Thank you again, Luis, and thanks to everyone who has contributed to the discussion here. We have now benchmarked the two designs against each other on the same dataset (the scripts are in attachment 208519), and we have discussed the result internally, including with Pedro, who wrote the separate items index patches on this bug. Our conclusion is that nested items is the right way forward for Koha, and that we should pick that one design rather than try to maintain two. In short: * On a 250k biblio / 1.26M item catalogue where one library holds 40% of the items, queries combining a title with an item-level limit (library, availability, item type + collection) took between 0.8 and 12.8 seconds cold on the separate index, against roughly 100 to 200 ms with nested items. The separate index has to fetch every matching biblionumber from the items index and pass them back as an ids filter, so its cost grows with the item-side set rather than with the query; a 39-hit title search limited to the large library took 7.3 seconds. Hit counts matched the independent oracle on both sides for same-item combinations. * Nested items gives same-item semantics, sorting and relevance-ordered pagination natively, without the intermediate set that Luis described in comment 63. * The write-side advantage of a separate index (no biblio reindex on a checkout) turned out to be small next to the read-side cost: on nested, a checkout-shaped change cost 27-39 ms at store time, plus a background reindex of 50-370 ms for records with 1 to 900 items. What this means for this bug: 1. We have obsoleted the patches attached here (the separate items index series). Pedro and I have talked this through and he is happy to proceed this way. Thank you Pedro, for framing the problem so well; several of the ideas carry over (the availability definition, batching the OPAC visibility checks, the reactive reindex triggers). 2. We would like to repurpose this bug (42835) as the home of the first piece of the nested items work: "index items as nested objects in the biblio document, together with the reindexing that keeps them correct". Luis, we would love for you to attach that first part of your branch here. 3. The branch is substantial (38 commits, about 5,600 lines), and it will be much easier for the community to review, test and QA if it is split across a small number of dependent bugs. We have done a QA review of it and will post that, together with a suggested split and some notes on the submission process, in a follow-up comment. The short version: the design is sound and the work is impressive. There are some changes needed, but all of them are fixable, and we would like to help get this over the line. David, thank you for the suggestion of supporting both. Given the limited QA resources we all have, we think picking one is the better path for now, but the modularity idea is a good one to keep in mind for the longer term. Thanks all. -- You are receiving this mail because: You are watching all bug changes.