On Fri, Apr 30, 2021 at 2:23 PM Peter Geoghegan <p...@bowt.ie> wrote: > I don't know how it's possible to do any of this without first > addressing what the table AM does in cases where heapam currently does > a non-HOT update.
Why can't it do what it does already? It's not broken for heap, so why should it be broken for anything else? And why are non-HOT updates specifically a problem? > You obviously cannot have the equivalent of > duplicate TIDs when your new table AM runs into these scenarios. So > what do you do instead? How do you make your clustered index/IoT style > identifiers (i.e. your strictly logical TID-like identifiers) deal > with that case? Is the problem you're worried about here that, with something like an index-organized table, you can have multiple row versions that have the same logical tuple ID, i.e. primary key value? And that the interfaces aren't well-suited to that? Because that's a problem I have thought about and can comment on, even though I think the question of having multiple versions with the same TID is distinguishable from the question of how *wide* TIDs should be. But maybe that's not what you are talking about here, in which case I guess I need a clearer explanation of the concern. -- Robert Haas EDB: http://www.enterprisedb.com
