Re: MaxOffsetNumber for Table AMs

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MaxOffsetNumber for Table AMs
Date: 2021-04-30 17:03:58
Message-ID: 79e4c7d85bf75e7bc6d7e8e6c741f6473210c322.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-04-30 17:10:13 Re: MaxOffsetNumber for Table AMs
Previous Message Tom Lane 2021-04-30 16:57:29 Re: Procedures versus the "fastpath" API