Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 79e4c7d85bf75e7bc6d7e8e6c741f6473210c322.camel@j-davis.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: MaxOffsetNumber for Table AMs
List pgsql-hackers
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?

> 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?

> I agree that it might well be useful to make TIDs fully logical (not
> "physiological" -- physical across blocks, logical within blocks) for
> some new table AM. Even then, it would still definitely be a good
> idea
> to make these logical TID values correlate with the physical table
> structure in some way.

Agreed.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Procedures versus the "fastpath" API
Next
From: Tom Lane
Date:
Subject: Re: MaxOffsetNumber for Table AMs