Repository navigation
Conversation
With only nleft >= and nright <= on the browsed category, the range read on the category index covers every following category, so MySQL computed the population from all the shop products and filtered the subtree last. Bounding nleft by the category nright is redundant in the nested set but makes the index range match the subtree.
The stock_available join went through product_attribute_combination, which repeated each combination stock row once per attribute. Joining it on product_attribute selects the same rows without the duplicates. The quantity summed to order the out of stock products last no longer counts a combination once per attribute: it is now the actual stock of the product.
Each attribute group and each feature facet ran its own count query, and each one recomputed the population of the category. The facets without selected value, and the AND features, share the current filters: their values are now counted in one query per facet type. A facet with a selected value keeps its own query, as it ignores its own selection. The values of the displayed features are also loaded in one query.
The "Not available" count filters on quantity and out_of_stock in the same operation, and each item got its own stock_available join on the same row. The stock fields are now flagged to share the join of their operation: the unique key of stock_available guarantees a single row. Operations on other tables keep one join per item, needed when they require several values.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
WHERE id_product IN (…)). Above 250k products, or when the population carries more than product columns, nothing changes.countOperations()in the adapter).Benchmark
Official PrestaShop 9.2 Docker image, MariaDB 11.4, 100k products with 3 combinations each, facet cache emptied before each request.
Pages with cached facets run exactly the same queries as before. Rendered pages and facet counts were compared with #1346 on 30 URLs: identical.
How to test
Empty the facet cache, then browse categories with various filters and sort orders: products and counts must match the current behaviour, and with an attribute filter the listing must still show the matching combination.