Re: Declarative partitioning

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Declarative partitioning
Date: 2015-08-20 16:00:19
Message-ID: CADkLM=eHdqDagQX631X=9jAi+c0i-fUJyv9xd3o5ExgyRzjRUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> My experiences with Oracle's hash function were generally not good -
> there's a reason many hash algorithms exist. If/when we do hash
> partitioning in Postgres I'd like to see the hash function be
> user-definable.
>

+1

In my experience, hash partitioning had one use: When you had run out of
ways to logically partition the data, AND you had two tables in a foreign
key relationship, AND that relationship was the most common use-case for
selecting the two tables. In which case, your one big join became 8 or 16
little ones, and all was well in the universe...

...until those little joins started to spill to disk, and now you need to
repartition by 2x hashes, and that basically means a reload of your primary
fact table, and a talk with a boss about why you painted yourself into a
corner when you first did that.

>
> Meanwhile, I think list and range are a good start. I'd prefer to see
> sub-partitioning before hash partitioning.
>

+1

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-08-20 16:09:44 Re: (full) Memory context dump considered harmful
Previous Message Joshua D. Drake 2015-08-20 15:57:19 Re: (full) Memory context dump considered harmful