On Fri, Apr 30, 2021 at 10:04 AM Jeff Davis <pg...@j-davis.com> wrote: > On Fri, 2021-04-30 at 08:36 -0700, Peter Geoghegan wrote: > > Compatibility with index AMs is more than a matter of switching out > > the tuple identifier -- if you invent something that has totally > > different performance characteristics for index AMs, then it's likely > > to break tacit assumptions about the cost of certain things. > > I think it would be reasonable to document and expect that table AMs > offer some locality of access for tuples with similar IDs. Do you think > we need something stronger than that?
I don't know. This conversation is still too abstract for me to be able to take a firm position. ISTM that we tend to talk about the table AM in excessively abstract terms. It would be a lot easier if we had clear fixed goals for a small number of additional table AMs. > > Plus deduplication ameliorates problems with version churn > > in > > indexes -- presumably the same problems will exist when any new table > > AM is used, and so it'll be useful to address the same problems in > > the > > same way. > > I got lost after "presumably the same problems", can you explain? Well, there are now two things in nbtree that specifically help with version churn caused by non-HOT updates: deduplication, and bottom-up index deletion (especially the latter). Presumably any new table AM will have something like non-HOT updates. Though they may rarely be a problem (say because the new table AM isn't really for OLTP), whenever they are a problem they'll be a very big problem. It seems like a good idea to have the same index AM level protections against accumulating version-churn index tuples in an unbounded way. More generally, it seems like a good idea to try to make new table AMs reasonably close to heapam insofar as possible. The reality is that everything evolved around heapam, and that that's likely to matter in all kinds of ways that nobody fully understands just yet. We have a somewhat abstract table AM interface, which is good, but that doesn't mean that table AMs can be designed as if it was a green field situation. -- Peter Geoghegan
