Re: [POC] hash partitioning
David Fetter <david@fetter.org>
From: David Fetter <david@fetter.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, amul sul <sulamul@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Yugo Nagata <nagata@sraoss.co.jp>, David Steele <david@pgmasters.net>, Greg Stark <stark@mit.edu>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-09-14T16:54:44Z
Lists: pgsql-hackers
On Mon, Sep 11, 2017 at 07:43:29AM -0400, Robert Haas wrote: > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: > >> Rebased 0002 against this commit & renamed to 0001, PFA. > > > > Given that we have default partition support now, I am wondering > > whether hash partitioned tables also should have default > > partitions. The way we have structured hash partitioning syntax, > > there can be "holes" in partitions. Default partition would help > > plug those holes. > > Yeah, I was thinking about that, too. On the one hand, it seems > like it's solving the problem the wrong way: if you've set up hash > partitioning properly, you shouldn't have any holes. Should we be pointing the gun away from people's feet by making hash partitions that cover the space automagically when the partitioning scheme[1] is specified? In other words, do we have a good reason to have only some of the hash partitions so defined by default? Best, David. [1] For now, that's just the modulus, but the PoC included specifying hashing functions, so I assume other ways to specify the partitioning scheme could eventually be proposed. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Commits
-
Add hash partitioning.
- 1aba8e651ac3 11.0 landed
-
Add sanity check for pg_proc.provariadic
- 35f059e9bdfb 11.0 landed
-
Add hash_combine64.
- b7f3eb31405f 11.0 landed
-
Make RelationGetPartitionDispatchInfo expand depth-first.
- 77b6b5e9ceca 11.0 cited
-
Introduce 64-bit hash functions with a 64-bit seed.
- 81c5e46c490e 11.0 cited
-
pg_dump: Add a --load-via-partition-root option.
- 23d7680d04b9 11.0 cited