On Mon, Mar 13, 2017 at 10:18 AM, Amit Kapila wrote:
> Agreed, so I have rebased your patch and passed heap_pages as -1 for
> index_only scans as discussed. Also, Rafia has tested with attached
> patch that parallel index and parallel index only scans are picked for
>
On Wed, Mar 8, 2017 at 6:58 PM, Robert Haas wrote:
> On Wed, Mar 8, 2017 at 7:04 AM, Amit Kapila wrote:
>> On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote:
>>> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila
On Wed, Mar 8, 2017 at 7:04 AM, Amit Kapila wrote:
> On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote:
>> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
>>> I think it can give us benefit in
>>> such cases as well
On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
>
>> I think it can give us benefit in
>> such cases as well (especially when we have to discard rows based heap
>> rows). Now, consider it
On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
> If we have lesser index pages and more heap pages, then we limit the
> parallelism based on index pages.
Kinda. In most cases, we figure out the degree of parallelism based
on heap pages and then we figure out the
On Tue, Mar 7, 2017 at 10:12 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila wrote:
>> I also think that commit didn't intend to change the behavior,
>> however, the point is how sensible is it to keep such behavior after
>>
On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila wrote:
> I also think that commit didn't intend to change the behavior,
> however, the point is how sensible is it to keep such behavior after
> Parallel Append. I am not sure if this is the right time to consider
> it or
On Tue, Mar 7, 2017 at 11:18 AM, Amit Kapila wrote:
> On Tue, Mar 7, 2017 at 10:22 AM, Ashutosh Sharma
> wrote:
>>> I also think that commit didn't intend to change the behavior,
>>> however, the point is how sensible is it to keep such behavior
On Tue, Mar 7, 2017 at 10:22 AM, Ashutosh Sharma wrote:
>> I also think that commit didn't intend to change the behavior,
>> however, the point is how sensible is it to keep such behavior after
>> Parallel Append. I am not sure if this is the right time to consider
>> it
> I also think that commit didn't intend to change the behavior,
> however, the point is how sensible is it to keep such behavior after
> Parallel Append. I am not sure if this is the right time to consider
> it or shall we wait till Parallel Append is committed.
>
>> I think the problem here is
On Tue, Mar 7, 2017 at 3:24 AM, Robert Haas wrote:
> On Sun, Mar 5, 2017 at 9:41 PM, Amit Kapila wrote:
>>> RCA:
>>>
>>> From "Replace min_parallel_relation_size with two new GUCs" commit
>>> onwards, we are not assigning parallel workers for
On Sun, Mar 5, 2017 at 9:41 PM, Amit Kapila wrote:
>> RCA:
>>
>> From "Replace min_parallel_relation_size with two new GUCs" commit
>> onwards, we are not assigning parallel workers for the child rel with
>> zero heap pages. This means we won't be able to create a
>
> Right, but OTOH, if we assign parallel workers by default, then it is
> quite possible that it would result in much worse plans. Consider a
> case where partition hierarchy has 1000 partitions and only one of
> them is big enough to allow parallel workers. Now in this case, with
> your
On Sat, Mar 4, 2017 at 9:52 PM, Ashutosh Sharma wrote:
> Hi All,
>
> From following git commit onwards, parallel seq scan is never getting
> selected for inheritance or partitioned tables.
>
>
> commit 51ee6f3160d2e1515ed6197594bda67eb99dc2cc
> Author: Robert Haas
Hi All,
>From following git commit onwards, parallel seq scan is never getting
selected for inheritance or partitioned tables.
commit 51ee6f3160d2e1515ed6197594bda67eb99dc2cc
Author: Robert Haas
Date: Wed Feb 15 13:37:24 2017 -0500
Replace
15 matches
Mail list logo