Exercise 3: Why [:20] Doesn't Fix the Real Performance Concern — Possible Solution
====================================================================

WHY [:20] DOESN'T SOLVE THE COST OF THE QUERY
------------------------------
[:20] limits how many results are returned to the caller, but it doesn't change how the database has to go about finding those matches in the first place. name__icontains compiles to a SQL LIKE '%...%' query with a wildcard at the start of the pattern, and a leading wildcard generally prevents a standard B-tree index from being used efficiently - the database may still need to scan a large portion of the table looking for anything that contains the search term, before it can even determine which 20 results to hand back. The expensive part (the scan) happens regardless of how small the final result slice is.

WHAT WOULD ACTUALLY HELP AT REAL SCALE
------------------------------
This chapter names a genuine full-text or trigram search feature - specifically mentioning PostgreSQL's own trigram extension - as the real fix once this became an actual bottleneck. Those features are built specifically to make substring/fuzzy matching efficient at scale, in a way a standard B-tree index on the column alone cannot, precisely because a leading-wildcard LIKE query defeats that kind of index.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that limiting result count doesn't reduce the underlying scan cost of a leading-wildcard LIKE query, and correctly names a genuine full-text/trigram search feature (as opposed to a bigger index or a smaller result slice) as what this chapter identifies as the real fix at scale.