On Fri, Apr 30, 2021 at 2:23 PM Peter Geoghegan <pg@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
