On Fri, Apr 30, 2021 at 12:20 PM Robert Haas <robertmh...@gmail.com> wrote: > 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?
No reason. > > 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. That's what I'm talking about. I'd like to hear what you think about it. It's not exactly a narrow concern. For one thing, it is enough to totally validate my suggestion about how we might widen TIDs and still have nbtree deduplication. -- Peter Geoghegan
