From: | Beena Emerson <memissemerson(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, amul sul <sulamul(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: [HACKERS] Runtime Partition Pruning |
Date: | 2018-01-01 06:22:39 |
Message-ID: | CAOG9ApG=6RfbJX6FB4Aj4+59YEOE517xDQ2KLFGh8hqRoOzvkA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello David,
On Wed, Dec 27, 2017 at 8:36 AM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> Please find attached my 4th version this patch.
Thanks for the patch
>
> This is now based on v17 of Amit's faster partition pruning patch [1].
> It also now includes Beena's tests which I've done some mostly
> cosmetic changes to.
>
> I've also fixed a few bugs, one in a case where I was not properly
> handling zero matching partitions in nodeAppend.c.
>
> Another change I've made is to now perform the partition pruning at
> run-time using a new memory context that's reset each time we
> redetermine the matching partitions. This was required since we're
> calling a planner function which might not be too careful about
> pfreeing memory it allocates. A test case I was running before making
> this change ended out failing to palloc memory due to OOM.
>
> I've not done anything about reducing the cost of the Append path when
> runtime pruning is enabled. I'm still thinking over the best way to
> handle that.
>
I think you are testing without asserts
The following assert fails: src/backend/optimizer/plan/setrefs.c :
set_plan_refs: ln 921
Assert(splan->plan.qual == NIL);
Append node now has runtime partition quals.
Also since the valid subplans are set in ExecInitAppend, the queries
with Init Plans do not work. I had moved it to ExecAppend in my patch
to handle the InitPlans as well.
DROP TABLE IF EXISTS prun_test_part;
CREATE TABLE prun_test_part (sal int) PARTITION BY RANGE(sal);
CREATE TABLE prun_test_part_p1 PARTITION OF prun_test_part FOR VALUES
FROM (0) TO (100);
CREATE TABLE prun_test_part_p2 PARTITION OF prun_test_part FOR VALUES
FROM (100) TO (200);
CREATE TABLE prun_test_part_p3 PARTITION OF prun_test_part FOR VALUES
FROM (200) TO (300);
CREATE TABLE prun_test_part_p4 PARTITION OF prun_test_part FOR VALUES
FROM (300) TO (400);
INSERT INTO prun_test_part VALUES (90), (100), (110), (200), (210),
(300), (310);
=# explain (analyze, costs off, summary off, timing off) SELECT * FROM
prun_test_part WHERE sal < (SELECT sal FROM prun_test_part WHERE sal =
200);
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.
--
Beena Emerson
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2018-01-01 10:12:16 | Re: [HACKERS] Transactions involving multiple postgres foreign servers |
Previous Message | Noah Misch | 2018-01-01 05:52:27 | Re: Increasing timeout of poll_query_until for TAP tests |