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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation
Дата
Msg-id CAH2-Wzmf39EE0h99AMyz_sEhJTAKK8AoyhB6y3g88GQCLLnNqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Mon, Apr 22, 2019 at 10:32 AM Stephen Frost <sfrost@snowman.net> wrote:
> Yes, global indexes for partitioned tables could potentially be simpler
> than the logical row identifiers, but maybe it'd be useful to just have
> one implementation based around logical row identifiers which ends up
> working for global indexes as well as the other types of indexes and
> table access methods.

Maybe so. I think that we'd have to actually try it out to know for sure.

> If we thought that the 'single-byte' partition number covered enough
> use-cases then we could possibly consider supporting them for partitions
> by just 'stealing' a byte from BlockIdData and having the per-partition
> size be limited to 4TB when a global index exists on the partitioned
> table.

I don't think that that would make it any easier to implement.

> This sounds pretty good to me, though I'm not nearly as close to the
> code there as you are.

I'm slightly concerned that I may have broken an index_form_tuple()
caller from some other access method, but they all seem to not trust
index_form_tuple() to have MAXALIGN()'d on their behalf, just like
nbtree (nbtree won't when I'm done, though, because it will actively
try to preserve the "real" tuple size). It's convenient to me that no
caller seems to rely on the index_form_tuple() MAXALIGN() that I want
to remove.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [PATCH v1] Add \echo_stderr to psql
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Allow any[] as input arguments for sql/plpgsql functions to mimic format()