Personal Catalogue: Django & PostgreSQL — Chapter 7, Exercise 3
====================================================

TASK
Explain why this project deliberately doesn't build a GIN index for
the full-text search field, and under what real condition that
decision should be revisited.

SOLUTION

WHAT THE SearchVector APPROACH ACTUALLY COSTS WITHOUT AN INDEX

The SearchVector('title', 'creator') call used in this chapter
recomputes the searchable text representation from the title and
creator columns fresh, on every single search query, rather than
reading a precomputed value. For a small table, this recomputation
cost is genuinely negligible - PostgreSQL can process a few hundred or
even a few thousand rows' worth of text transformation quickly enough
that no user would ever notice a delay.

WHY THIS PROJECT DELIBERATELY SKIPS THE GIN INDEX

Building a proper indexed setup means adding a dedicated
SearchVectorField column, keeping it updated whenever title or creator
changes (via a signal, a trigger, or overriding save()), and creating a
real GIN index over that field - genuine additional development and
maintenance work. A personal book/CD/DVD/Blu-ray catalogue realistically
holds a few hundred to a few thousand items at most - nowhere near the
scale where the unindexed approach's own recomputation cost would
become a real, user-noticeable problem. Given this project's own
established real time pressure (Chapter 1), spending real setup effort
optimizing for a scale the project will likely never reach isn't a
reasonable priority right now.

UNDER WHAT CONDITION THIS SHOULD BE REVISITED

If the catalogue's own real item count grew dramatically past what a
personal collection would realistically contain - into the tens of
thousands of rows or beyond - the per-query recomputation cost would
start to become genuinely measurable, and at that point building the
indexed SearchVectorField/GIN index setup would become a real,
justified investment rather than premature optimization. The right
trigger for revisiting this isn't a fixed number so much as an actual
observed slowdown in real search response times as the collection
genuinely grows.

ANSWER: The unindexed SearchVector approach recomputes its search text
on every query, which is a real but genuinely negligible cost at the
scale a personal catalogue actually reaches - so building the more
involved GIN-indexed setup now would be real, unnecessary extra work
given this project's own time pressure. That decision should be
revisited only if the catalogue's real size grows dramatically beyond
a personal collection's realistic scale, to the point where search
performance is actually, measurably affected.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains the real cost the unindexed approach actually incurs, ties
the decision not to build the index directly back to this project's own
already-established time-pressure constraint, and names a concrete,
observable condition (measurable slowdown at genuine scale) rather than
an arbitrary row-count threshold as the real trigger for revisiting it.