On Fri, Mar 30, 2018 at 1:41 AM, Robert Haas wrote:
> On Thu, Mar 29, 2018 at 12:55 AM, Amit Kapila wrote:
>> I think that is under acceptable range. I am seeing few regression
>> failures with the patch series. The order of targetlist seems to have
>> changed for Remote SQL. Kindly find the f
On Thu, Mar 29, 2018 at 12:55 AM, Amit Kapila wrote:
> I think that is under acceptable range. I am seeing few regression
> failures with the patch series. The order of targetlist seems to have
> changed for Remote SQL. Kindly find the failure report attached. I
> have requested my colleague A
On Thu, Mar 29, 2018 at 2:31 AM, Robert Haas wrote:
> On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote:
>>
>> The above block takes 43700.0289 ms on Head and 45025.3779 ms with the
>> patch which is approximately 3% regression.
>
> Thanks for the analysis -- the observation that this seemed to
On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote:
> Good idea, such an optimization will ensure that the cases reported
> above will not have regression. However isn't it somewhat beating the
> idea you are using in the patch which is to avoid modifying the path
> in-place?
Sure, but you can't
On Tue, Mar 27, 2018 at 10:59 PM, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote:
>> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote:
>>> If we don't want to go with the upperrel logic, then maybe we should
>>> consider just merging some of the other changes from my p
On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote:
>> If we don't want to go with the upperrel logic, then maybe we should
>> consider just merging some of the other changes from my previous patch
>> in 0003* patch you have posted and then se
On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote:
> If we don't want to go with the upperrel logic, then maybe we should
> consider just merging some of the other changes from my previous patch
> in 0003* patch you have posted and then see if it gets rid of all the
> cases where we are seeing a
On Tue, Mar 27, 2018 at 3:08 AM, Robert Haas wrote:
> On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila wrote:
>> For me, it is equivalent to the master. The average of ten runs on
>> the master is 20664.3683 and with all the patches applied it is
>> 20590.4734. I think there is some run-to-run vari
On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila wrote:
> For me, it is equivalent to the master. The average of ten runs on
> the master is 20664.3683 and with all the patches applied it is
> 20590.4734. I think there is some run-to-run variation, but more or
> less there is no visible degradation.
On Sat, Mar 24, 2018 at 8:41 AM, Robert Haas wrote:
> On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote:
>> Yeah, sometimes that kind of stuff change performance characteristics,
>> but I think what is going on here is that create_projection_plan is
>> causing the lower node to build physical t
On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote:
> Yeah, sometimes that kind of stuff change performance characteristics,
> but I think what is going on here is that create_projection_plan is
> causing the lower node to build physical tlist which takes some
> additional time. I have tried bel
On Tue, Mar 20, 2018 at 1:23 AM, Robert Haas wrote:
> On Sat, Mar 17, 2018 at 1:16 AM, Amit Kapila wrote:
>> Test-1
>> --
>> DO $$
>> DECLARE count integer;
>> BEGIN
>> For count In 1..100 Loop
>> Execute 'explain Select ten from tenk1';
>> END LOOP;
>> END;
>> $$;
>>
>> In the above
On Sat, Mar 17, 2018 at 1:16 AM, Amit Kapila wrote:
> Test-1
> --
> DO $$
> DECLARE count integer;
> BEGIN
> For count In 1..100 Loop
> Execute 'explain Select ten from tenk1';
> END LOOP;
> END;
> $$;
>
> In the above block, I am explaining the simple statement which will
> have just
On Fri, Mar 16, 2018 at 3:36 PM, Amit Kapila wrote:
> On Wed, Mar 14, 2018 at 12:01 AM, Robert Haas wrote:
>>
>> 0003 introduces a new upper relation to represent the result of
>> applying the scan/join target to the topmost scan/join relation. I'll
>> explain further down why this seems to be n
On Fri, Mar 16, 2018 at 6:06 AM, Amit Kapila wrote:
> I think in the patch series this is the questionable patch wherein it
> will always add an additional projection path (whether or not it is
> required) to all Paths (partial and non-partial) for the scanjoin rel
> and then later remove it (if n
On Wed, Mar 14, 2018 at 12:01 AM, Robert Haas wrote:
>
> 0003 introduces a new upper relation to represent the result of
> applying the scan/join target to the topmost scan/join relation. I'll
> explain further down why this seems to be needed. Since each path
> must belong to only one relation,
On Wed, Feb 14, 2018 at 5:37 AM, Amit Kapila wrote:
> Your concern is valid, but isn't the same problem exists in another
> approach as well, because in that also we can call
> adjust_paths_for_srfs after generating gather path which means that we
> might lose some opportunity to reduce the relati
On Sun, Mar 11, 2018 at 5:49 PM, Amit Kapila wrote:
>
>> +/* Add projection step if needed */
>> +if (target && simple_gather_path->pathtarget != target)
>>
>> If the target was copied someplace, this test will fail. Probably we want to
>> check containts of the PathTarget structure? Righ
On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat
wrote:
>
>
After recent commits, the patch doesn't get applied cleanly, so
rebased it and along the way addressed the comments raised by you.
> Here are some comments on the patch.
>
> +/*
> + * Except for the topmos
On Mon, Feb 19, 2018 at 9:56 AM, Ashutosh Bapat
wrote:
> On Mon, Feb 19, 2018 at 9:35 AM, Ashutosh Bapat
> wrote:
>> On Sat, Feb 17, 2018 at 8:17 AM, Amit Kapila wrote:
>>> On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat
>>> wrote:
On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila
wrote:
On Mon, Feb 19, 2018 at 9:35 AM, Ashutosh Bapat
wrote:
> On Sat, Feb 17, 2018 at 8:17 AM, Amit Kapila wrote:
>> On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat
>> wrote:
>>> On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila
>>> wrote:
On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat
wrote
On Sat, Feb 17, 2018 at 8:17 AM, Amit Kapila wrote:
> On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat
> wrote:
>> On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila wrote:
>>> On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat
>>> wrote:
I happened to look at the patch for something else. But here
On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat
wrote:
> On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila wrote:
>> On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat
>> wrote:
>>> I happened to look at the patch for something else. But here are some
>>> comments. If any of those have been already disc
On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila wrote:
> On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat
> wrote:
>> I happened to look at the patch for something else. But here are some
>> comments. If any of those have been already discussed, please feel
>> free to ignore. I have gone through the
On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat
wrote:
> I happened to look at the patch for something else. But here are some
> comments. If any of those have been already discussed, please feel
> free to ignore. I have gone through the thread cursorily, so I might
> have missed something.
>
> In
I happened to look at the patch for something else. But here are some
comments. If any of those have been already discussed, please feel
free to ignore. I have gone through the thread cursorily, so I might
have missed something.
In grouping_planner() we call query_planner() first which builds the
On Fri, Feb 2, 2018 at 12:15 AM, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 11:48 PM, Amit Kapila wrote:
>
> The other cases aren't so clear. In the case of the first call within
> create_ordered_paths, there's no loss in the !is_sorted case because
> apply_projection_to_path will be getting c
On Wed, Jan 31, 2018 at 11:48 PM, Amit Kapila wrote:
> I can see what you have in mind, but I think we still need to change
> the parallel safety flag of the path if *_target is not parallel safe
> either inside apply_projection_to_path or may be outside where it is
> called.
Hmm. You have a po
On Tue, Jan 30, 2018 at 3:30 AM, Robert Haas wrote:
> On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote:
>> If we want to get rid of Gather (Merge) checks in
>> apply_projection_to_path(), then we need some way to add a projection
>> path to the subpath of gather node even if that is capable of
On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote:
> If we want to get rid of Gather (Merge) checks in
> apply_projection_to_path(), then we need some way to add a projection
> path to the subpath of gather node even if that is capable of
> projection as we do now. I think changing the order of
On Sat, Jan 27, 2018 at 2:50 AM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 6:38 AM, Amit Kapila wrote:
>> [ new patch ]
>
> I think that grouping_planner() could benefit from a slightly more
> extensive rearrangement. With your patch applied, the order of
> operations is:
>
> 1. compute the s
On Tue, Jan 2, 2018 at 6:38 AM, Amit Kapila wrote:
> [ new patch ]
I think that grouping_planner() could benefit from a slightly more
extensive rearrangement. With your patch applied, the order of
operations is:
1. compute the scan/join target
2. apply the scan/join target to all paths in curr
On Fri, Dec 29, 2017 at 7:56 PM, Marina Polyakova
wrote:
> Hello everyone in this thread!
>
> On 29-11-2017 8:01, Michael Paquier wrote:
>>
>> Moved to next CF for extra reviews.
>
>
> Amit, I would like to ask some questions about your patch (and can you
> please rebase it on the top of the maste
Hello everyone in this thread!
On 29-11-2017 8:01, Michael Paquier wrote:
Moved to next CF for extra reviews.
Amit, I would like to ask some questions about your patch (and can you
please rebase it on the top of the master?):
1)
+ path->total_cost -= (target->cost.per_tuple - oldcost.per_
On Fri, Nov 10, 2017 at 4:42 AM, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 3:47 AM, Amit Kapila wrote:
>> I think I understood your concern after some offlist discussion and it
>> is primarily due to the inheritance related check which can skip the
>> generation of gather paths when it shouldn'
35 matches
Mail list logo
