Christopher Browne <cbbrowne@gmail.com> writes:
> There would indeed be merit in improving the partitioning apparatus,
> and actually, I think it's been a couple of years since there has been
> serious discussion of this.
We could certainly use a partitioning mechanism that's easier to use
than what we have now, which is basically "build it yourself, here's
the parts bin". There would also be some performance benefits from
moving the partitioning logic into hard-wired code.
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.
regards, tom lane