On Mon, Jul 19, 2021 at 4:31 PM Chris Cleveland <cclevel...@dieselpoint.com> wrote: > I'm confused on how to handle transactions and visibility.
In Postgres, indexes are not considered to be part of the logical database. They're just data structures that point to TIDs in the table. To an index, each TID is just another object -- it doesn't possess any built-in idea about MVCC. In practice the indexes may be able to surmise certain things about MVCC and versioning, as an optimization -- but that is all speculative and relies on cooperation from the table AM side. Also, the implementation of unique indexes knows more than zero about versions, since that's just necessary. These two cases may or may not be considered exceptions to the general rule. I suppose that it's a matter of perspective. > So... how do I handle this? Is there some way for me to implement my own > storage manager that manages visibility? This is the responsibility of a table AM, not any one index AM. In general we assume that each table AM implements something very much like heapam's VACUUM implementation. Index AMs may also have opportunistic cleanup of their own, as an optimization (actually this is what I was referring to). Theoretically index AMs and table AMs are orthogonal things. How true that will be in a world with more than one mature table AM remains to be seen. -- Peter Geoghegan
