Re: [HACKERS] [POC] hash partitioning

Поиск
Список
Период
Сортировка
От Jesper Pedersen
Тема Re: [HACKERS] [POC] hash partitioning
Дата
Msg-id ba5ee631-18eb-cf78-e6f5-4060e988120e@redhat.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [POC] hash partitioning  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] [POC] hash partitioning  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 09/14/2017 12:56 PM, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 12:54 PM, David Fetter <david@fetter.org> wrote:
>> 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?
> 
> Sure, we can add some convenience syntax for that, but I'd like to get
> the basic stuff working before doing that kind of polishing.
> 
> If nothing else, I assume Keith Fiske's pg_partman will provide a way
> to magically DTRT about an hour after this goes in.  But probably we
> can do better in core easily enough.
> 

Yeah, it would be nice to have a syntax like

) PARTITION BY HASH (col) WITH (AUTO_CREATE = 64);

But then there also needs to be a way to create the 64 associated 
indexes too for everything to be easy.

Best regards, Jesper


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE insteadof UNBOUNDED for range partition b
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?