Exercise 3: Immutable Documents and the Conceptual Echo of MVCC — Possible Solution ==================================================================== WHY DOCUMENTS ARE EFFECTIVELY IMMUTABLE AT THE SEGMENT LEVEL ------------------------------ Per this chapter's own warn-box, "because a change to one document can require updating potentially many different postings lists across the inverted index — every term that document contained — Elasticsearch/ OpenSearch documents are actually immutable at the underlying segment level once written. An 'update' is really implemented as marking the old document deleted and indexing a brand-new one." If a document like "the quick brown fox" were modified in place — say, changing "fox" to "cat" — the engine would need to locate and update potentially SEVERAL separate postings lists across the inverted index: removing this document's reference from the "fox" entry, and adding it to a (possibly new) "cat" entry, while leaving "the," "quick," and "brown" untouched. Because a single document typically contains many distinct terms, a genuine in-place update could require touching many scattered postings-list entries throughout the index — a much more invasive, expensive operation than simply overwriting one row's own data would be in a traditional row-based table. To avoid this complexity and cost, the engine instead treats each written document as immutable: an "update" is implemented as marking the OLD document deleted (so it no longer shows up in future searches) and indexing an entirely NEW document with the updated content, building fresh postings-list entries for it, rather than surgically modifying the existing postings lists in place. THE CONCEPTUAL ECHO OF POSTGRES1-9'S OWN MVCC MATERIAL ------------------------------ Per this chapter, "this is conceptually reminiscent of postgres1-9's own MVCC material (a new tuple per update), though for a genuinely different underlying reason and mechanism." Per postgres1-9, Postgres never modifies a row in place on UPDATE either — it creates an entirely new tuple with a new xmin, marking the old tuple as superseded via xmax, rather than editing the existing tuple's bytes directly. The SHAPE of the pattern is the same in both systems: rather than mutating existing data in place, an update is handled by creating something new and marking the old version obsolete. WHY THIS IS A CONCEPTUAL ECHO, NOT A MECHANICAL ONE ------------------------------ The two systems reach this same "new version, not in-place edit" pattern for genuinely different reasons. Postgres's MVCC uses this pattern specifically to give every transaction a consistent SNAPSHOT view without needing heavy locking (per postgres1-9's own concurrency- focused explanation). This chapter's own reasoning is entirely different: Elasticsearch/OpenSearch's immutability exists because editing scattered postings-list entries across the inverted index in place would be prohibitively complex and expensive, not because of any concurrency/snapshot-consistency goal. The two systems arrived at a similarly-shaped solution (new version instead of in-place edit) for two genuinely unrelated underlying problems — which is precisely why the chapter calls it a conceptual echo rather than claiming the two mechanisms are actually the same thing. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains specifically why in-place updates would be expensive here (scattered postings-list changes across many terms), and explicitly distinguishes the SHAPE of the pattern (shared with MVCC) from the REASON for it (genuinely different in each system), matching the chapter's own careful "conceptual, not mechanical" framing.