| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Beena Emerson <memissemerson(at)gmail(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: | 2017-12-27 03:06:44 |
| Message-ID: | CAKJS1f_jejNN7Tw-E95MD0W-4PtxEjsDYKNvJATEoLz0sJou+A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Please find attached my 4th version this 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.
[1] https://www.postgresql.org/message-id/58c3e20a-a964-4fdb-4e7d-bd833e9bead1@lab.ntt.co.jp
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| runtime_prune_drowley_v4.patch | application/octet-stream | 82.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2017-12-27 03:27:08 | Re: AS OF queries |
| Previous Message | Adam Lee | 2017-12-27 02:18:03 | Re: Should we nonblocking open FIFO files in COPY? |