From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Beena Emerson <memissemerson(at)gmail(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: path toward faster partition pruning |
Date: | 2017-10-25 06:47:46 |
Message-ID: | bd98dca1-340f-43ea-fcb4-099aa563594d@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
0001-Add-new-tests-for-partition-pruning-v3.patch | text/plain | 35.4 KB |
0002-Planner-side-changes-for-partition-pruning-v3.patch | text/plain | 41.0 KB |
0003-Implement-get_partitions_from_clauses-v3.patch | text/plain | 31.1 KB |
0004-Some-interface-changes-for-partition_bound_-cmp-bsea-v3.patch | text/plain | 10.1 KB |
0005-Implement-get_partitions_for_keys-v3.patch | text/plain | 20.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-10-25 07:37:05 | Re: path toward faster partition pruning |
Previous Message | Amit Khandekar | 2017-10-25 06:10:00 | Re: UPDATE of partition key |