Re: Declarative partitioning
От | David Steele |
---|---|
Тема | Re: Declarative partitioning |
Дата | |
Msg-id | 55D5C9E5.6040900@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Declarative partitioning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Declarative partitioning
|
Список | 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@lab.ntt.co.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@pgmasters.net
В списке pgsql-hackers по дате отправления: