Re: [HACKERS] Hash Functions - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [HACKERS] Hash Functions
Date
Msg-id CAMp0ubdfskZkHToYzYkUUhidJft7CSgOZ_nM9cRUa8BXijsbcQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Hash Functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Hash Functions  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Christoph Berg
Date:
Subject: Re: [HACKERS] 10beta1 sequence regression failure on sparc64
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands