Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation
Date
Msg-id 20190422163540.3732sqgirnrsvyfx@alap3.anarazel.de
Whole thread Raw
In response to Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation
Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation
List pgsql-hackers
Hi,

On 2019-04-21 17:46:09 -0700, Peter Geoghegan wrote:
> Andres has suggested that I work on teaching nbtree to accommodate
> variable-width, logical table identifiers, such as those required for
> indirect indexes, or clustered indexes, where secondary indexes must
> use a logical primary key value instead of a heap TID.

I think it's two more cases:

- table AMs that want to support tables that are bigger than 32TB. That
  used to be unrealistic, but it's not anymore. Especially when the need
  to VACUUM etc is largely removed / reduced.
- global indexes (for cross-partition unique constraints and such),
  which need a partition identifier as part of the tid (or as part of
  the index key, but I think that actually makes interaction with
  indexam from other layers more complicated - the inside of the index
  maybe may want to represent it as a column, but to the outside that
  ought not to be visible)



> Thoughts?

Seems reasonable to me.

I, more generally, wonder if there's not a case to squeeze out more
padding than "just" what you describe (since we IIRC don't frequently
keep pointers into such tuples anyway, and definitely don't for byval
attrs). But that's very likely better done separately.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: clean up docs for v12
Next
From: Bruce Momjian
Date:
Subject: Re: finding changed blocks using WAL scanning