Hi, On 2019-04-15 14:11:02 -0400, Robert Haas wrote: > I hate to pick on any particular part of the tree, but it seems > entirely plausible to me that a second columnar storage implementation > could deliver more incremental value than spgist, an index AM you > committed. We should not move the goal posts into the stratosphere > here.
Oh, I forgot: I agree that we don't need to be absurdly picky - but I also think that table storage is much more crucial to get right than index storage, which is already plenty crucial. Especially when that type of index is not commonly usable for constraints. It really sucks to get wrong query results due to a corrupted index / wrong index implementation - but if your table AM level corruption, you're *really* in a dark place. There's no way to just REINDEX and potentially recover most information with a bit of surgery. Sure there can be app level consequences to wrong query results that can be really bad, and lead to very permanent data loss. On-disk compat is also much more important for table level data - it's annoying to have to reindex indexes after an upgrade, but at least it can be done concurrently after the most important indexes are operational. Greetings, Andres Freund