Exercise 3: The Determining Factors, Named Concretely — Possible Solution ==================================================================== THE TASK ------------------------------ Name at least three of this chapter's own concrete determining factors for when a dedicated search engine is actually worth it, using this chapter's own material and postgres1-6's own original guidance. FACTOR 1: WHETHER SEARCH IS A PRIMARY PRODUCT FEATURE OR A SECONDARY CONVENIENCE ------------------------------ Per this chapter, "search is the primary product, not a secondary feature — a job-search site, a documentation search product, an e-commerce search-and-discovery experience where search quality directly drives revenue" is one of the concrete situations favoring a dedicated engine. This directly echoes postgres1-6's own original framing that its own built-in search fits "when search is a secondary feature of a primarily-relational application." Whether search is the actual product itself, or merely a helper feature inside a different kind of application, is the chapter's own first real determining factor. FACTOR 2: WHETHER GENUINE SCALE REQUIRES REAL HORIZONTAL DISTRIBUTION ------------------------------ Per this chapter, "genuinely large scale requiring real horizontal distribution (search1-8) that a single Postgres server or read-replica setup can't practically match" is a second named factor. This directly extends postgres1-6's own "at moderate scale" qualifier — the determining question isn't scale in the abstract, but whether the actual, concrete scale genuinely exceeds what a single, well-resourced relational server (even with read replicas) can practically continue to serve. FACTOR 3: WHETHER FACETED SEARCH/AGGREGATIONS ARE A FIRST-CLASS PRODUCT REQUIREMENT ------------------------------ Per this chapter, "faceted search/aggregations (search1-7) are a first-class, heavily-used product requirement, not an occasional nice-to-have" is named as a third determining factor. This directly resolves postgres1-6's own "faceted search as a first-class feature" callout (formally closed in search1-7) — whether a product genuinely, heavily depends on real-time faceted filtering, as opposed to only occasionally wanting it, materially changes whether the dedicated engine's own real strength in this area is actually being used. FACTOR 4 (BONUS): WHETHER RELEVANCE QUALITY ITSELF DRIVES PRODUCT SUCCESS ------------------------------ Per this chapter, "sophisticated relevance tuning (search1-6's own BM25/boosting material) genuinely matters to the product's own success, not just 'good enough' matching" is also named. This directly follows from search1-6's own honest ts_rank()-vs-BM25 comparison — whether the DIFFERENCE in relevance sophistication between the two approaches would genuinely be noticed and matter to real users, or whether "good enough" matching already satisfies the actual product need. WHY THIS WORKS AS AN ANSWER ------------------------------ It names at least three (in fact four, exceeding the minimum) of the chapter's own specific determining factors, using the chapter's own precise wording for each, and explicitly ties each one back to postgres1-6's own original guidance to show these factors are a real, detailed elaboration of that earlier chapter's own deferred question, not an unrelated new framework.