From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Declarative partitioning |
Date: | 2015-08-20 12:36:53 |
Message-ID: | 55D5C9E5.6040900@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/20/15 5:45 AM, Amit Langote wrote:
> On 2015-08-20 PM 06:27, Pavan Deolasee wrote:
>> On Tue, Aug 18, 2015 at 4:00 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp
>>> wrote:
>>>
>>> PARTITION BY LIST ON (name)
>>> PARTITION BY RANGE ON (year, month)
>>>
>>> PARTITION BY LIST ON ((lower(left(name, 2)))
>>> PARTITION BY RANGE ON ((extract(year from d)), (extract(month from d)))
>>>
>>>
>>
>> How about HASH partitioning? Are there plans to support foreign tables as
>> partitions?
>>
>
> I've not given HASH partitioning a lot of thought yet. About the latter,
> it seems it should not be too difficult to incorporate into the proposed
> partitioning internals.
Hash partitioning seems like it could wait. If fact, I've nearly always
implemented hash partitions as list partitions. This gives me control
over the hash function and allows me to use properties of the key to my
advantage. For instance - if your key is a sha1 hash there's no need to
rehash, just grab the required number of bits off the end of the key.
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.
Meanwhile, I think list and range are a good start. I'd prefer to see
sub-partitioning before hash partitioning.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-08-20 12:39:31 | Re: Extension upgrade and GUCs |
Previous Message | Paul Ramsey | 2015-08-20 12:21:15 | Re: Extension upgrade and GUCs |