Hi Amit,

On 15.04.2016 07:35, Amit Langote wrote:
Thanks a lot for the comments. The patch set changed quite a bit since the last version. Once the CF entry was marked returned with feedback on March 22, I held off sending the new version at all. Perhaps, it would have been OK. Anyway here it is, if you are interested. I will create an entry in CF 2016-09 for the same. Also, see below replies to you individual comments.


Thanks for your new patch! I've tried it and discovered some strange behavior for partitioning by composite key. Here is an example of my setup:

create table test(a int, b int) partition by range (a, b);
create table test_1 partition of test for values start (0, 0) end (100, 100); create table test_2 partition of test for values start (100, 100) end (200, 200); create table test_3 partition of test for values start (200, 200) end (300, 300);

It's alright so far. But if we try to insert record in which attribute 'a' belongs to one partition and attribute 'b' belongs to another then record will be inserted in the first one:

insert into test(a, b) values (150, 50);

select tableoid::regclass, * from test;
 tableoid |  a  | b
----------+-----+----
 test_2   | 150 | 50
(1 row)

I think there should be an error because value for 'b' violates range constraint for test_2. Now if we query data from 'test' and add filter b < 100, then planner will exclude partitions 'test_2' (which actually contains inserted row) and 'test_3' and return nothing:

select * from test where b < 100;
 a | b
---+---
(0 rows)

explain (costs off) select * from test where b < 100;
        QUERY PLAN
---------------------------
 Append
   ->  Seq Scan on test
         Filter: (b < 100)
   ->  Seq Scan on test_1
         Filter: (b < 100)
(5 rows)

--
Ildar Musin
i.mu...@postgrespro.ru



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

Reply via email to