From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] path toward faster partition pruning |
Date: | 2018-02-19 04:59:28 |
Message-ID: | ec7418ea-5900-7773-8260-60451f3538ea@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David.
On 2018/02/17 18:24, David Rowley wrote:
> On 2 February 2018 at 23:03, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> I started wondering if it's not such a good idea to make
>> PartitionClauseInfo a Node at all? I went back to your earlier message
>> [1] where you said that it's put into the Append node for run-time pruning
>> to use, but it doesn't sound nice that we'd be putting into the plan
>> something that's looks more like scratchpad for the partition.c code. I
>> think we should try to keep PartitionClauseInfo in partition.h and put
>> only the list of matched bare clauses into Append.
>
> That sounds like a good idea.
>
> A patch which puts this back is attached.
>
> I've changed the run-time prune patch to process the clause lists
> during execution instead.
Thank you. I'll incorporate it in the version I'll send next.
Regards,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-02-19 05:01:12 | Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath |
Previous Message | Ashutosh Bapat | 2018-02-19 04:26:35 | Re: [HACKERS] why not parallel seq scan for slow functions |