Re: [HACKERS] path toward faster partition pruning
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | bd98dca1-340f-43ea-fcb4-099aa563594d@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Beena Emerson <memissemerson@gmail.com>) |
Ответы |
Re: [HACKERS] path toward faster partition pruning
|
Список | pgsql-hackers |
Thanks a lot Rajkumar and Beena for the tests. On 2017/10/24 1:38, Beena Emerson wrote: > On Mon, Oct 23, 2017 at 3:24 PM, Rajkumar Raghuwanshi wrote: >> Thanks for updated patches, I am able to compile it on head. >> >> While testing this, I got an observation, pruning is not scanning default >> partition leading to wrong output. below is test to reproduce this. >> >> create table rp (a int, b varchar) partition by range (a); >> create table rp_p1 partition of rp default; >> create table rp_p2 partition of rp for values from (1) to (10); >> create table rp_p3 partition of rp for values from (10) to (maxvalue); >> >> insert into rp values (-1,'p1'); >> insert into rp values (1,'p2'); >> insert into rp values (11,'p3'); >> >> postgres=# select tableoid::regclass,* from rp; >> tableoid | a | b >> ----------+----+---- >> rp_p2 | 1 | p2 >> rp_p3 | 11 | p3 >> rp_p1 | -1 | p1 >> (3 rows) >> >> --with pruning >> postgres=# explain (costs off) select * from rp where a <= 1; >> QUERY PLAN >> -------------------------- >> Append >> -> Seq Scan on rp_p2 >> Filter: (a <= 1) >> (3 rows) >> >> postgres=# select * from rp where a <= 1; >> a | b >> ---+---- >> 1 | p2 >> (1 row) Both this (wrong output)... > I had noticed this and also that this crash: > > tprt PARTITION BY RANGE(Col1) > tprt_1 FOR VALUES FROM (1) TO (50001) PARTITION BY RANGE(Col1) > tprt_11 FOR VALUES FROM (1) TO (10000), > tprt_1d DEFAULT > tprt_2 FOR VALUES FROM (50001) TO (100001) > > EXPLAIN (COSTS OFF) SELECT * FROM tprt WHERE col1 BETWEEN 20000 AND 70000; > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > !> ...and this (crash) were due to bugs in the 0005 patch. Output with the updated patch for Rajkumar's test: explain (costs off ) select * from rp where a <= 1; QUERY PLAN -------------------------- Append -> Seq Scan on rp_p2 Filter: (a <= 1) -> Seq Scan on rp_p1 Filter: (a <= 1) (5 rows) select tableoid::regclass, * from rp where a <= 1; tableoid | a | b ----------+----+---- rp_p2 | 1 | p2 rp_p1 | -1 | p1 (2 rows) -- moreover select tableoid::regclass, * from rp where a < 1; tableoid | a | b ----------+----+---- rp_d | -1 | p1 (1 row) Should be fixed in the attached updated version. While fixing the bugs, I made some significant revisions to the code introduced by 0005. No significant changes to any of the patches 0001-0004. Thanks, Amit -- 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 по дате отправления: