Check if promotions exist without extra db query

[katafrakt]

Description

Using @promotions.any? causes an extra db query (SELECT DISTINCT ... LIMIT 1, see below). Instead, we can force-load the dataset and check its length, because it is used few lines down (@promotions.each).

Relevant fragment from logs:

(625.5ms)  SELECT COUNT(DISTINCT "spree_promotions"."id") FROM "spree_promotions" LEFT OUTER JOIN "spree_promotion_codes" ON "spree_promotion_codes"."promotion_id" = "spree_promotions"."id" WHERE "spree_promotion_codes"."value" ILIKE '%f66e%'
Spree::Promotion Exists (616.3ms)  SELECT  DISTINCT "spree_promotions".* FROM "spree_promotions" LEFT OUTER JOIN "spree_promotion_codes" ON "spree_promotion_codes"."promotion_id" = "spree_promotions"."id" WHERE "spree_promotion_codes"."value" ILIKE '%f66e%' LIMIT 1 OFFSET 15
Spree::Promotion Load (1258.6ms)  SELECT  DISTINCT "spree_promotions".* FROM "spree_promotions" LEFT OUTER JOIN "spree_promotion_codes" ON "spree_promotion_codes"."promotion_id" = "spree_promotions"."id" WHERE "spree_promotion_codes"."value" ILIKE '%f66e%' ORDER BY "spree_promotions"."id" DESC LIMIT 15 OFFSET 15

Here, the query in second line is caused by @promotions.any?. It disappears after applying this change.

Performance:

It can have quite significant (positive) performance impact when there is a lot of promotions and someone is searching (b-tree index does not work for ILIKE '%f66e%, so seq scan is used). Sometimes the page even times out on that.

According to my tests on local env with ~20 million of promotion codes in 2500 promotions it can save about 20-25% of time used on rendering this view.

Checklist:

• I have followed Pull Request guidelines
• I have added a detailed description into each commit message
• I have updated Guides and README accordingly to this change (if needed)
• I have added tests to cover this change (if needed)
• I have attached screenshots to this PR for visual changes (if needed)

[kennyadsl]

Hey @katafrakt, thanks! Have you also already tried with .exists?. It should still hit the database with an extra query but it looks like it's way more optimized for larger record sets than any?.

[katafrakt]

@kennyadsl unfortunately it seems that exists? generates same db query:

(3875.5ms)  SELECT COUNT(DISTINCT "spree_promotions"."id") FROM "spree_promotions" LEFT OUTER JOIN "spree_promotion_codes" ON "spree_promotion_codes"."promotion_id" = "spree_promotions"."id" WHERE "spree_promotion_codes"."value" ILIKE '%f66d%'
Spree::Promotion Exists (3499.2ms)  SELECT  DISTINCT "spree_promotions".* FROM "spree_promotions" LEFT OUTER JOIN "spree_promotion_codes" ON "spree_promotion_codes"."promotion_id" = "spree_promotions"."id" WHERE "spree_promotion_codes"."value" ILIKE '%f66d%' LIMIT 1 OFFSET 0
Spree::Promotion Load (3484.0ms)  SELECT  DISTINCT "spree_promotions".* FROM "spree_promotions" LEFT OUTER JOIN "spree_promotion_codes" ON "spree_promotion_codes"."promotion_id" = "spree_promotions"."id" WHERE "spree_promotion_codes"."value" ILIKE '%f66d%' ORDER BY "spree_promotions"."id" DESC LIMIT 15 OFFSET 0

[kennyadsl]

You are right, I was reading that any? and exists? produce different queries but probably it doesn't happen in this context for some reason (maybe the LEFT OUTER JOIN?).

Thanks, @katafrakt!