Re: MaxOffsetNumber for Table AMs

On Fri, Apr 30, 2021 at 12:20 PM Robert Haas <robertmhaas(at)gmail(dot)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