| 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-21 13:00:26 |
| Message-ID: | CAKJS1f-uv90VELKx34ov-d17sQ1vJg5jUvj19K2xa86f6eieKA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 22 December 2017 at 01:43, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
>> I wonder if Robert understands the extent of the problem. The patch
>> will be useful to prune away partitions when the partitioned table is
>> on the inside of a parameterised nested loop join, but I think we'll
>> likely get some complaints about PREPARE statements always using a
>> custom plan. It's going to make this pretty hard to write regression
>> tests for unless we went and invent some GUC "prefer_generic_plan", or
>> "generic_plan_cost_multiplier" to provide a way to coax
>> choose_custom_plan() into not choosing a custom plan. I admit to not
>> having the answer to this but I don't think we should rule out
>> discussing possible fixes.
>
> I have attached the regression tests I am currently using to check my
> patch. It has few prepared statements using runtime pruning.
Thanks for sending. Will the tests still pass if you remove the hack
from choose_custom_plan()?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ildar Musin | 2017-12-21 13:02:06 | Re: General purpose hashing func in pgbench |
| Previous Message | Robert Haas | 2017-12-21 12:56:51 | Re: [HACKERS] parallel.c oblivion of worker-startup failures |