Re: Thoughts on nbtree with logical/varwidth table identifiers, v12 on-disk representation

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Thoughts on nbtree with logical/varwidth table identifiers, v12 on-disk representation
Date: 2019-04-22 16:35:40
Message-ID: 20190422163540.3732sqgirnrsvyfx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-04-22 16:35:42 Re: finding changed blocks using WAL scanning
Previous Message Tom Lane 2019-04-22 16:33:24 Re: clean up docs for v12