On Fri, 16 Nov 2018 at 07:50, Tom Lane wrote:
> I pushed this with a bit of extra tweaking --- notably, I added an
> Assert to ExecFindMatchingSubPlans to guard against the possibility
> that someone calls it when the remapping hasn't been done.
Thanks for pushing.
> I am not really convinced th
"Imai, Yoshikazu" writes:
> I changed the state of this patch to "Ready for Committer".
I pushed this with a bit of extra tweaking --- notably, I added an
Assert to ExecFindMatchingSubPlans to guard against the possibility
that someone calls it when the remapping hasn't been done.
I think that t
On Mon, Oct 22, 2018 at 8:31 PM, David Rowley wrote:
> On 18 October 2018 at 16:13, Imai, Yoshikazu
> wrote:
> > The patch improves the performance about 1.3% which is less than
> > David's result, but it seems still improves the performance.
>
> Thanks for doing these benchmarks.
>
> The speedu
On 18 October 2018 at 16:13, Imai, Yoshikazu
wrote:
> The patch improves the performance about 1.3% which is less than David's
> result, but it seems still improves the performance.
Thanks for doing these benchmarks.
The speedup is small, but it becomes much more significant once other
bottlenec
Sorry for the delay in replying.
On Wed, Oct 10, 2018 at 4:05 PM, David Rowley wrote:
> > It seems to me that there is no problem in this patch as far.
> > Is there another thing I have to do for the review?
>
> There's a checklist in [1]. Perhaps there's something mentioned there
> that you've m
On 11 October 2018 at 16:00, Imai, Yoshikazu
wrote:
> On Thu, Sept 6, 2018 at 7:30 PM, David Rowley wrote:
>> I've also included an additional test to ensure the other_subplans
>> gets updated correctly. The other tests for this seem to only perform
>> run-time pruning during init plan and do no f
On Tue, Oct 9, 2018 at 1:24 AM, I wrote:
> On Mon, Oct 8, 2018 at 1:00 AM, David Rowley wrote:
> > I've attached an updated patch which skips the re-sequence work when
> > doing that is not required for anything.
>
>
>
> I saw the patch and it seems good to me about the codes.
> I still couldn't
On Tue, Oct 9, 2018 at 2:02 AM, David Rowley wrote:
> Yeah, so subplan_map is just an array that stores the List index of
> the Append or MergeAppend's subplans. When we perform run-time pruning
> during executor initialisation, if we prune away some of these
> subplans then we don't initialise tho
On 9 October 2018 at 14:23, Imai, Yoshikazu
wrote:
> I checked codes and I think so too.
>
> Confirmation of my understanding and For more information to others:
>
> The subplan map is used when we call ExecFindInitialMatchingSubPlans or
> ExecFindMatchingSubPlans.
> ExecFindInitialMatchingSubPlan
Hi, David.
Thanks for the patch!
On Mon, Oct 8, 2018 at 1:00 AM, David Rowley wrote:
> I was looking at this again and I realised that we can completely skip
> the re-sequence of the subplan map when we're not going to perform any
> further pruning during execution.
I checked codes and I think so
On 7 September 2018 at 19:29, David Rowley wrote:
> While reviewing some other patches to improve partitioning performance
> I noticed that one of the loops in ExecFindInitialMatchingSubPlans()
> could be coded a bit more efficiently. The current code loops over
> all the original subplans checki
While reviewing some other patches to improve partitioning performance
I noticed that one of the loops in ExecFindInitialMatchingSubPlans()
could be coded a bit more efficiently. The current code loops over
all the original subplans checking if the subplan is newly pruned, if
it is, the code sets
12 matches
Mail list logo
