Hello everybody.
Recently I have tried to upgrade our postgres instalation from 9.1 to 9.3,
but one query in particular got extremelly slow. The query is:
EXPLAIN ANALYZE SELECT *
FROM sellable
LEFT JOIN storable ON storable.product_id =
product.id LEFT JOIN sellable_category
SUM(product_stock_item.quantity) AS stock,
SUM((product_stock_item.quantity*product_stock_item.stock_cost)) AS total_stock_cost
FROM storable
CROSS JOIN branch
LEFT JOIN product_stock_item ON product_stock_item.branch_id =
branch.id WHERE
(_stock_summary.branch_id = '04c3a996-f7c1-11e2-9274-000ae4372716' OR _stock_summary.branch_id IS NULL)
AND stoq_normalize_string(sellable.description) ILIKE stoq_normalize_string('%ray%')
AND stoq_normalize_string(sellable_category.description) ILIKE stoq_normalize_string('%receit%')
On 9.1 it runs in about 500ms, while on a later version, it takes a lot more
than 180000ms (thats 0.5 seconds vs 3 minutes).
Even though this might not be the most well writen query, thats quite some
time difference.
A few things to notice:
- stoq_normalize_string is a wrapper around unaccent marking it as
unmutable, so it can be used to create an index
- The original query has a few more joins but I removed the most I could
without influencing the results.
- The query is actually created using python-storm (an orm for python)
Using git bisect I have found that the problem starts with commit
5b7b5518d0ea56c422a197875f7efa5deddbb388 (And the times I posted above are
from this commit and its parent).
Now this is as far as I can investigate, since my knowledge of the
postgresql inners are between null and zero
Trying to find out where the problem is, here are a few thinks that I have
tried that changed the speed (but does not really fix it for me):
- Replace stoq_normalize_string with unaccent
- Remove the branch_id IS NULL from the where clause
- Remove the left join with sellable_category
There you can download an extract from the database with the needed tables
to reproduce the problem.
So, finally, the question is: Is this a regression or was I just luck in the first place
that the query was 'fast enought' and this is a somewhat expected behaviour
for this query?
--
Ronaldo Maia