Re: Hash partitioning.

On Tue, Jun 25, 2013 at 4:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> However, I find it hard to think that hash partitioning as such is very
> high on the to-do list. As was pointed out upthread, the main practical
> advantage of partitioning is *not* performance of routine queries, but
> improved bulk-data management such as the ability to do periodic
> housecleaning by dropping a partition. If your partitioning is on a
> hash, you've thrown away any such advantage, because there's no
> real-world meaning to the way the data's been split up. So I find range
> and list partitioning way more plausible.

It would be nice if range partitioning based on some user-defined
function was completely automatic, as in:

* You define a function that returns a partition name for a given input.
* You define a table to somehow be auto-partitioned on
your_function(some_column)
* The planner knows now it's some_column applied to your_function, so
it can do constraint exclusion checks (your_function would probably
need to be stable at least)
* If a returned partition is missing... what? (auto-create? that'd be nice)

It's pretty much what we have already, albeit easier to use. And,
perhaps constraint exclusion logic could be specialized for this case,
and made more robust.