On 07/03/17 02:46, Amit Kapila wrote:
On Mon, Mar 6, 2017 at 6:49 PM, Robert Haas wrote:
On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
I was going to do it after index and index-only scans and parallel
bitmap heap scan were committed, but
On Mon, Mar 6, 2017 at 6:49 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
>
> I was going to do it after index and index-only scans and parallel
> bitmap heap scan were committed, but I've been holding off on
>
On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
> On Mon, Mar 6, 2017 at 4:57 PM, Michael Banck
> wrote:
>> Hi,
>>
>> On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
>>> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas
On Mon, Mar 6, 2017 at 4:57 PM, Michael Banck wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
>> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
>> > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas
Hi,
On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
> > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
> >> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
>> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
>> wrote:>
>>> support related patch. In anycase, to avoid
On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote:>
>> support related patch. In anycase, to avoid confusion I am attaching
>> all the three patches with this e-mail.
>
> Committed
On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote:>
> support related patch. In anycase, to avoid confusion I am attaching
> all the three patches with this e-mail.
Committed guc_parallel_index_scan_v1.patch, with changes to the
documentation and GUC descriptions.
--
On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote:
> Here second part of the comment (but have not yet advanced ..) seems
> to be slightly misleading because this state has nothing to do with
> the advancement of scan keys.
>
> I have not changed this because I am not
On Wed, Feb 15, 2017 at 2:04 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 12:48 PM, Robert Haas wrote:
>> That sounds way better.
>
> Here's an updated patch. Please review my changes, which include:
>
> * Various comment updates.
1.
+ *
On Tue, Feb 14, 2017 at 12:48 PM, Robert Haas wrote:
> That sounds way better.
Here's an updated patch. Please review my changes, which include:
* Various comment updates.
* _bt_parallel_seize now unconditionally sets *pageno to P_NONE at the
beginning, instead of doing
On Mon, Feb 13, 2017 at 9:04 PM, Amit Kapila wrote:
> I think the comment at that place is not as clear as it should be. So
> how about changing it as below:
>
> Existing comment:
> --
> /*
> * For parallel scans, get the last page scanned as it
On Mon, Feb 13, 2017 at 5:47 PM, Robert Haas wrote:
> On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote:
> Why can't we rely on _bt_walk_left?
The reason is mentioned in comments, but let me try to explain with
some example. When
On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote:
Why can't we rely on _bt_walk_left?
>>> The reason is mentioned in comments, but let me try to explain with
>>> some example. When you reach that point of code, it means that either
>>> the current page (assume
On Fri, Feb 10, 2017 at 11:27 PM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote:
>>> The hunk in indexam.c looks like a leftover that can be omitted.
>>
>> It is not a leftover hunk. Earlier, the patch has the same check
>>
On Sat, Feb 11, 2017 at 9:41 PM, Robert Haas wrote:
> On Fri, Feb 10, 2017 at 11:22 PM, Amit Kapila wrote:
>>> Why can't we rely on _bt_walk_left?
>>
>> The reason is mentioned in comments, but let me try to explain with
>> some example. When you
On Fri, Feb 10, 2017 at 11:22 PM, Amit Kapila wrote:
>> Why can't we rely on _bt_walk_left?
>
> The reason is mentioned in comments, but let me try to explain with
> some example. When you reach that point of code, it means that either
> the current page (assume page
On Fri, Feb 10, 2017 at 11:27 PM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote:
>>> The hunk in indexam.c looks like a leftover that can be omitted.
>>
>> It is not a leftover hunk. Earlier, the patch has the same check
>>
On Thu, Feb 9, 2017 at 1:33 AM, Amit Kapila wrote:
> compute_index_pages_v2.patch - This function extracts the computation
> of index pages to be scanned in a separate function and used it in
> existing code. You will notice that I have pulled up the logic of
>
On Wed, Feb 1, 2017 at 8:20 AM, Amit Kapila wrote:
>> The hunk in indexam.c looks like a leftover that can be omitted.
>
> It is not a leftover hunk. Earlier, the patch has the same check
> btparallelrescan, but based on your comment up thread [1] (Why does
>
On Thu, Feb 9, 2017 at 5:34 AM, Amit Kapila wrote:
>> What about parallel CREATE INDEX? The patch currently uses
>> min_parallel_relation_size as an input into the optimizer's custom
>> cost model. I had wondered if that made sense. Note that another such
>> input is the
On Thu, Feb 9, 2017 at 12:08 PM, Peter Geoghegan wrote:
> On Wed, Feb 8, 2017 at 10:33 PM, Amit Kapila wrote:
>> I had some offlist discussion with Robert about the above point and we
>> feel that keeping only heap pages for parallel computation might not
On Wed, Feb 8, 2017 at 10:33 PM, Amit Kapila wrote:
> I had some offlist discussion with Robert about the above point and we
> feel that keeping only heap pages for parallel computation might not
> be future proof as for parallel index only scans there might not be
> any
On Sat, Feb 4, 2017 at 7:14 AM, Amit Kapila wrote:
> On Sat, Feb 4, 2017 at 5:54 AM, Robert Haas wrote:
>> On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote:
>
>> On balance, I'm somewhat inclined to think that we ought
On Sat, Feb 4, 2017 at 5:54 AM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote:
>> Yeah, I understand that point and I can see there is strong argument
>> to do that way, but let's wait and see what others including Robert
On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote:
> Yeah, I understand that point and I can see there is strong argument
> to do that way, but let's wait and see what others including Robert
> have to say about this point.
It seems to me that you can make an argument
On Wed, Feb 1, 2017 at 10:20 PM, Amit Kapila wrote:
> makes sense, so changed accordingly.
I have moved this patch to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 02/01/2017 06:50 PM, Amit Kapila wrote:
Used large table parallel index scans (both forward and backward
scans). These tests have been done by Tushar and you can find
detailed report up thread [2]. Apart from that, the patch has been
tested with TPC-H queries at various scale factors and it
On 02/01/2017 06:50 PM, Amit Kapila wrote:
Used large table parallel index scans (both forward and backward
scans). These tests have been done by Tushar and you can find
detailed report up thread [2]. Apart from that, the patch has been
tested with TPC-H queries at various scale factors and it
On Wed, Feb 1, 2017 at 3:52 AM, Robert Haas wrote:
> On Tue, Jan 24, 2017 at 4:51 PM, Robert Haas wrote:
>> On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
>>> In spite of being careful, I missed reorganizing the
Hello Robert,
>I am a bit mystified about how this manages to work with array keys.
>_bt_parallel_done() won't set btps_pageStatus to BTPARALLEL_DONE
>unless so->arrayKeyCount >= btscan->btps_arrayKeyCount, but
>_bt_parallel_advance_scan() won't do anything unless btps_pageStatus
>is already
On Tue, Jan 31, 2017 at 5:53 PM, Rahila Syed wrote:
> Hello,
>
>>Agreed, that it makes sense to consider only the number of pages to
>>scan for computation of parallel workers. I think for index scan we
>>should consider both index and heap pages that need to be scanned
On Tue, Jan 24, 2017 at 4:51 PM, Robert Haas wrote:
> On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
>> In spite of being careful, I missed reorganizing the functions in
>> genam.h which I have done in attached patch.
>
> Cool. Committed
Hello,
>Agreed, that it makes sense to consider only the number of pages to
>scan for computation of parallel workers. I think for index scan we
>should consider both index and heap pages that need to be scanned
>(costing of index scan consider both index and heap pages). I thin
>where
On Sat, Jan 28, 2017 at 1:34 AM, Robert Haas wrote:
> On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
>> parallel_index_opt_exec_support_v6 - Removed the usage of
>> GatherSupportsBackwardScan. Expanded the comments in
>> ExecReScanIndexScan.
On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
> parallel_index_opt_exec_support_v6 - Removed the usage of
> GatherSupportsBackwardScan. Expanded the comments in
> ExecReScanIndexScan.
I looked through this and in general it looks reasonable to me.
However, I did
On Fri, Jan 27, 2017 at 6:53 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Jan 23, 2017 at 5:07 PM, Amit Kapila
> wrote:
>>
>> On Fri, Jan 20, 2017 at 7:29 AM, Haribabu Kommi
>> wrote:
>> > I didn't find any better names
On Mon, Jan 23, 2017 at 5:07 PM, Amit Kapila
wrote:
> On Fri, Jan 20, 2017 at 7:29 AM, Haribabu Kommi
> wrote:
> >
> > On Thu, Jan 19, 2017 at 1:18 AM, Amit Kapila
> > wrote:
> >> >
> >> > +extern BlockNumber
On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote:
> In spite of being careful, I missed reorganizing the functions in
> genam.h which I have done in attached patch.
Cool. Committed parallel-generic-index-scan.2.patch. Thanks.
--
Robert Haas
EnterpriseDB:
On Fri, Jan 20, 2017 at 7:29 AM, Haribabu Kommi
wrote:
>
> On Thu, Jan 19, 2017 at 1:18 AM, Amit Kapila
> wrote:
>> >
>> > +extern BlockNumber _bt_parallel_seize(IndexScanDesc scan, bool
>> > *status);
>> > +extern void
On Sat, Jan 21, 2017 at 12:23 PM, Amit Kapila wrote:
> On Sat, Jan 21, 2017 at 1:15 AM, Robert Haas wrote:
>>
>> I think it's a good idea to put all three of those functions together
>> in the listing, similar to what we did in
>>
On Sat, Jan 21, 2017 at 1:15 AM, Robert Haas wrote:
> On Fri, Jan 20, 2017 at 9:29 AM, Amit Kapila wrote:
>> Sure, if scan keys have changed then we can't continue, but this is
>> the case where runtime keys are first time initialized.
>>
>> if
On Fri, Jan 20, 2017 at 9:29 AM, Amit Kapila wrote:
> Sure, if scan keys have changed then we can't continue, but this is
> the case where runtime keys are first time initialized.
>
> if (node->iss_NumRuntimeKeys != 0 && !node->iss_RuntimeKeysReady)
>
> In the above
On Fri, Jan 20, 2017 at 3:41 AM, Robert Haas wrote:
> On Wed, Jan 18, 2017 at 8:03 AM, Amit Kapila wrote:
>>> Why do we need separate AM support for index_parallelrescan()? Why
>>> can't index_rescan() cover that case?
>>
>> The reason is that
On Fri, Jan 20, 2017 at 12:59 AM, Robert Haas wrote:
> On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila wrote:
>> Fixed.
>
>
> If all of that were no issue, the considerations in
> TargetListSupportsBackwardScan could be a problem, too. But I think
>
On Thu, Jan 19, 2017 at 1:18 AM, Amit Kapila
wrote:
> On Wed, Jan 18, 2017 at 6:25 AM, Haribabu Kommi
> wrote:
> >
> >
> > On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila
> > wrote:
> >>
> >
> > + *
On Wed, Jan 18, 2017 at 8:03 AM, Amit Kapila wrote:
>> Why do we need separate AM support for index_parallelrescan()? Why
>> can't index_rescan() cover that case?
>
> The reason is that sometime index_rescan is called when we have to
> just update runtime scankeys in
On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila wrote:
> Fixed.
I think that the whole idea of GatherSupportsBackwardScan is wrong.
Gather doesn't support a backwards scan under any circumstances,
whether the underlying node does or not. You can read the tuples
once, in
On Thu, Jan 19, 2017 at 12:28 AM, Robert Haas wrote:
> On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
>> Fixed.
>
> With respect to the second patch
> (parallel_index_opt_exec_support_v4.patch), I'm hoping it can use the
> new function from
On Wed, Jan 18, 2017 at 6:25 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila
> wrote:
>>
>>
>> Changed as per suggestion.
>>
>>
>> I have also rebased the optimizer/executor support patch
>>
On Tue, Jan 17, 2017 at 11:27 PM, Robert Haas wrote:
> On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
>> Fixed.
>
> Thanks for the update. Some more comments:
>
> It shouldn't be necessary for MultiExecBitmapIndexScan to modify the
>
On Wed, Jan 18, 2017 at 6:55 PM, Rahila Syed wrote:
> >+ /* Check if the scan for current scan keys is finished */
> >+ if (so->arrayKeyCount < btscan->btps_arrayKeyCount)
> >+ *status = false;
>
> >I didn't clearly understand, in which scenario the arrayKeyCount is less
On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
> Fixed.
With respect to the second patch
(parallel_index_opt_exec_support_v4.patch), I'm hoping it can use the
new function from Dilip's bitmap heap scan patch set. See commit
716c7d4b242f0a64ad8ac4dc48c6fed6557ba12c.
On Wed, Jan 18, 2017 at 8:03 AM, Amit Kapila wrote:
> On Tue, Jan 17, 2017 at 11:27 PM, Robert Haas wrote:
>> On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
>> WAIT_EVENT_PARALLEL_INDEX_SCAN is in fact btree-specific.
On Wed, Jan 18, 2017 at 6:25 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila
> wrote:
>>
>
> + * index_beginscan_parallel - join parallel index scan
>
> The name and the description doesn't sync properly, any better
On Tue, Jan 17, 2017 at 11:27 PM, Robert Haas wrote:
> On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
>
>
> WAIT_EVENT_PARALLEL_INDEX_SCAN is in fact btree-specific. There's no
> guarantee that any other AMs the implement parallel index scans
>+ /* Check if the scan for current scan keys is finished */
>+ if (so->arrayKeyCount < btscan->btps_arrayKeyCount)
>+ *status = false;
>I didn't clearly understand, in which scenario the arrayKeyCount is less
>than btps_arrayKeyCount?
Consider following array scan keys
select * from test2 where
On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila
wrote:
>
> Changed as per suggestion.
>
>
> I have also rebased the optimizer/executor support patch
> (parallel_index_opt_exec_support_v4.patch) and added a test case in
> it.
Thanks for the patch. Here are comments found
On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote:
> Fixed.
Thanks for the update. Some more comments:
It shouldn't be necessary for MultiExecBitmapIndexScan to modify the
IndexScanDesc. That seems really broken. If a parallel scan isn't
supported here (and I'm sure
On Fri, Jan 13, 2017 at 11:06 PM, Robert Haas wrote:
> On Fri, Jan 13, 2017 at 9:28 AM, Anastasia Lubennikova
> wrote:
>> I didn't find any case of noticeable performance degradation,
>> so set status to "Ready for committer".
>
> The very
On Fri, Jan 13, 2017 at 7:58 PM, Anastasia Lubennikova
wrote:
> 27.12.2016 17:33, Amit Kapila:
>
>
> The similar problem has occurred while testing "parallel index only
> scan" patch and Rafia has included the fix in her patch [1] which
> ideally should be included
On Fri, Jan 13, 2017 at 9:28 AM, Anastasia Lubennikova
wrote:
> I didn't find any case of noticeable performance degradation,
> so set status to "Ready for committer".
The very first hunk of doc changes looks like it makes the whitespace
totally wrong - surely it
27.12.2016 17:33, Amit Kapila:
On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova
wrote:
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
wrote:
The following review has been posted through the
On Fri, Dec 23, 2016 at 5:48 PM, Rahila Syed wrote:
>>> 5. Comment for _bt_parallel_seize() says:
>>> "False indicates that we have reached the end of scan for
>>> current scankeys and for that we return block number as P_NONE."
>>>
>>> What is the reason to check (blkno
On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova
wrote:
> 22.12.2016 07:19, Amit Kapila:
>>
>> On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
>> wrote:
>>>
>>> The following review has been posted through the commitfest
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant:
>> 5. Comment for _bt_parallel_seize() says:
>> "False indicates that we have reached the end of scan for
>> current scankeys and for that we return block number as P_NONE."
>>
>> What is the reason to check (blkno == P_NONE) after checking (status ==
false)
>> in _bt_first() (see code below)?
On 12/23/2016 05:38 PM, Robert Haas wrote:
So why are you reporting it here rather than on a separate thread?
We found it -while testing parallel index scan and later it turned out
to be crash in general.
Sure- make sense ,will do that.
--
regards,tushar
--
Sent via pgsql-hackers mailing
On Fri, Dec 23, 2016 at 1:35 AM, tushar wrote:
> In addition to that, we run the sqlsmith against PG v10+PIS (parallel index
> scan) patches and found a crash but that is coming on plain PG v10
> (without applying any patches) as well
So why are you reporting it
On 12/22/2016 01:35 PM, tushar wrote:
On 12/22/2016 09:49 AM, Amit Kapila wrote:
I think you can focus on the handling of array scan keys for testing.
In general, one of my colleagues has shown interest in testing this
patch and I think he has tested as well but never posted his findings.
I
On Thu, Dec 22, 2016 at 9:49 AM, Amit Kapila wrote:
> On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
> wrote:
>> The following review has been posted through the commitfest application:
>> make installcheck-world: tested, passed
>>
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
>
Thanks for reviewing! A few quick thoughts from me since I write a
bunch of the design for this patch.
On Wed, Dec 21, 2016 at 10:16 AM, Anastasia Lubennikova
wrote:
> 1. Can't we simply use "if (scan->parallel_scan != NULL)" instead of
> xs_temp_snap flag?
>
> +
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi, thank you for the patch.
Results are very promising. Do
On Sat, Nov 26, 2016 at 10:35 PM, Amit Kapila
wrote:
> On Sat, Oct 22, 2016 at 9:07 AM, Amit Kapila
> wrote:
> > On Fri, Oct 21, 2016 at 10:55 PM, Robert Haas
> wrote:
>
> I have rebased the patch (parallel_index_scan_v2)
On Sat, Oct 22, 2016 at 9:07 AM, Amit Kapila wrote:
> On Fri, Oct 21, 2016 at 10:55 PM, Robert Haas wrote:
I have rebased the patch (parallel_index_scan_v2) based on latest
commit e8ac886c (condition variables). I have removed the usage of
On Fri, Oct 21, 2016 at 10:55 PM, Robert Haas wrote:
> On Fri, Oct 21, 2016 at 9:27 AM, Amit Kapila wrote:
>>> I think the parallel_workers reloption should override the degree of
>>> parallelism for any sort of parallel scan on that table. Had I
On Fri, Oct 21, 2016 at 9:27 AM, Amit Kapila wrote:
>> I think the parallel_workers reloption should override the degree of
>> parallelism for any sort of parallel scan on that table. Had I
>> intended it to apply only to sequential scans, I would have named it
>>
On Thu, Oct 20, 2016 at 10:33 PM, Robert Haas wrote:
> On Wed, Oct 19, 2016 at 11:07 PM, Amit Kapila wrote:
>>> Ideally, the parallel_workers storage parameter will rarely be
>>> necessary because the optimizer will generally do the right thing in
On Wed, Oct 19, 2016 at 11:07 PM, Amit Kapila wrote:
>> Ideally, the parallel_workers storage parameter will rarely be
>> necessary because the optimizer will generally do the right thing in
>> all case.
>
> Yeah, we can choose not to provide any parameter for parallel
On Wed, Oct 19, 2016 at 8:07 PM, Amit Kapila wrote:
> I have also checked and found that you are right. In SQL Server, they
> are using max degree of parallelism (MAXDOP) parameter which is I
> think is common for all the sql statements.
It's not just that one that does
On Thu, Oct 20, 2016 at 7:39 AM, Peter Geoghegan wrote:
> On Mon, Oct 17, 2016 at 8:08 PM, Amit Kapila wrote:
>> Create Index With (parallel_workers = 4);
>>
>> If above syntax looks sensible, then we might need to think what
>> should be used for
On Mon, Oct 17, 2016 at 8:08 PM, Amit Kapila wrote:
> Create Index With (parallel_workers = 4);
>
> If above syntax looks sensible, then we might need to think what
> should be used for parallel index build. It seems to me that parallel
> tuple sort patch [1]
On Tue, Oct 18, 2016 at 4:08 PM, Rahila Syed wrote:
>>Another point which needs some thoughts is whether it is good idea to
>>use index relation size to calculate parallel workers for index scan.
>>I think ideally for index scans it should be based on number of pages
>>to
>Another point which needs some thoughts is whether it is good idea to
>use index relation size to calculate parallel workers for index scan.
>I think ideally for index scans it should be based on number of pages
>to be fetched/scanned from index.
IIUC, its not possible to know the exact number of
On Thu, Oct 13, 2016 at 8:48 AM, Amit Kapila wrote:
> As of now, the driving table for parallel query is accessed by
> parallel sequential scan which limits its usage to a certain degree.
> Parallelising index scans would further increase the usage of parallel
> query in
86 matches
Mail list logo