Re: [HACKERS] [POC] hash partitioning

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] [POC] hash partitioning
Дата
Msg-id CAFiTN-sui+qh7+1S1XUfzMTC32TRvzTRcUNU1dYo4FVcjp1YcQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [POC] hash partitioning  (amul sul <sulamul@gmail.com>)
Ответы Re: [HACKERS] [POC] hash partitioning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, Jun 6, 2017 at 1:03 PM, amul sul <sulamul@gmail.com> wrote:
> May I ask you, how you sure about 8 is an unfit value for t1 relation?
> And what if the value other than 8, for e.g. 7?

Well, First I created t1 as a leaf relation like below, and I tested
insert into t1 with value 8 and it was violating the partition
constraint of t1, however, 7 was fine.

create table t (a int) partition by hash(a);
create table t1 partition of t for values with (modulus 2, remainder 1);

Later I dropped this t1 and created 2 level partition with the leaf as a range.

drop table t1;
create table t1 partition of t for values with (modulus 2, remainder
1) partition by range(a);
create table t1_1 partition of t1 for values from (8) to (10);

So now, I am sure that t1_1 can accept the value 8 and its parent t1 can't.

So I think this can only happen in the case of partitioned by hash
that a value is legal for the child but illegal for the parent?  Isn't
it a good idea that if a user is inserting in the top level relation
he should know for which partition exactly the constraint got
violated?

>
> Updated patch attached.

Thanks.


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: [HACKERS] Fix tab-completion of ALTER SUBSCRIPTION SET PUBLICATION
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table