On Tue, Jun 25, 2013 at 4:32 PM, Tom Lane <t...@sss.pgh.pa.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
