Re: [HACKERS] Hash Functions

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: [HACKERS] Hash Functions
Дата
Msg-id CAMp0ubdfskZkHToYzYkUUhidJft7CSgOZ_nM9cRUa8BXijsbcQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Hash Functions  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Hash Functions  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, May 17, 2017 at 12:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 1. To handle dump-and-reload the way we partitioning does today, hash
> functions would need to be portable across encodings.
> 2. That's impractically difficult.
> 3. So let's always load data through the top-parent.
> 4. But that could fail due to e.g. a UNIQUE index on an individual
> child, so let's try to prohibit all of the things that could be done
> to an individual partition that could cause a reload failure.
> 5. And then for good measure let's hide the existence of the partitions, too.

That is one thread of logic, but out of the discussion also
highlighted some of the consequences of treating hash partitions like
range/list partitions.

For instance, it makes little sense to have individual check
constraints, indexes, permissions, etc. on a hash-partitioned table.
It doesn't mean that we should necessarily forbid them, but it should
make us question whether combining range and hash partitions is really
the right design.

Regards,    Jeff Davis



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

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: [HACKERS] 10beta1 sequence regression failure on sparc64
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands