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 I've been holding off on
committing parallel bitm
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
> committing parallel bitmap heap scan waiting for Andres
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 wrote:
>>> > On Wed, Feb 15, 2017 at 1:39 PM, 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 wrote:
>> >> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila
>> >>
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
> >> wrote:>
> >>> support related patch. In anycase, to avoid conf
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 confusion I am attaching
>>> all the three patches with this e-mail.
>>
>> Commi
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 guc_parallel_index_scan_v1.patch, with changes to the
> docu
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.
--
Robert Haas
EnterpriseDB:
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 sure what you have in mind.
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.
+ * BTPARALLEL_IDLE indicates that no backend is currentl
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 it conditionally at the
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 is quite
> * possible that
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 you reach that point of code, it means that either
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 page number is 10) doesn't co
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
>> btparallelrescan, but based on your comment up t
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 reach that point of code, it means that either
>>
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 number is 10) doesn't contain
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
>> btparallelrescan, but based on your comment up t
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
> conversion of clauses to indexquals
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
> btparallelrescan cater to the case whe
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 projected size of the fina
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
>> be future proof as for parallel index
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 heap pages. So, it is bet
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 to base
>> everything on heap pages, so that we're always measuring in the
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
>> have to say about this point.
>
> It seems to
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 for any point of view.
In a
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:
http://www.postgresql.org/mailpref/pgsql-hac
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 functions in
>>> genam.h which I have done in attached patch.
>>
>> Cool. Comm
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 BTPAR
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
>>(costing of index scan c
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 parallel-generic-index-scan.2.patch. Thanks.
Review
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 consider
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.
>
> I looked through this and in general it looks
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 notice one thing that I thi
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 other than the following,
>> >
>> > _bt_get_next_parallel_page
>> > _bt_set_next_
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 _bt_parallel_seize(IndexScanDesc scan, bool
> >> > *status);
> >> > +extern void _bt_p
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: http://www.enterprisedb.com
The Ente
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 _bt_parallel_release(IndexScanDesc scan, BlockNumber
>> > scan_page);
>> >
>>
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
>> 69d34408e5e7adcef8ef2f4e9c4f2919637e9a06 for FDWs. After all they
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 (node->iss_NumRuntimeKeys != 0 && !node->iss_Runtime
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 check, the second part of the c
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 sometime index_rescan is called when we have to
>> j
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
> there shouldn't be any issue having Gather just c
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:
> >>
> >
> > + * index_beginscan_parallel - join parallel index scan
> >
> > The name and the description doesn't s
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 index and we don't want to re
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 order, and you can't back up
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 Dilip's bitmap heap scan patch set. See commit
> 7
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
>> (parallel_index_opt_exec_support_v4.patch) and added a test case in
>> it.
>
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
> IndexScanDesc. That seems really broken. If a parallel
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
> >than btps_arrayKeyCoun
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.
--
Robert Haas
Enterpri
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. There's no
>> guarantee that any other AMs the implement parallel index
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 description?
>
This can be called by both the work
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 will
> use that wait event, and they might have
>+ /* 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 during review.
parallel_i
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 that's the case right now
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 first hunk of doc changes looks like it makes the whitesp
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 in this patch, so I have copied
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 can't be right to have 0-space in
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 commitfest application:
make installcheck-world: tested,
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 == P_NONE) after checkin
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 application:
>>> make installcheck-world: tested, passed
>>> I
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: tested, passed
Docume
>> 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)? I
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 li
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 here rather than on a separate
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 will
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
>> Implements feature: tested, passed
>> Spec complia
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
> Documentation:test
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?
>
> + if (scan->xs_temp_snap)
>
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 y
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) based on latest
> commit e8ac886c (condition variables). I have removed
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
ConditionVariablePrepareToSleep as that is is no longer
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
>>> intended it to apply only to sequential scans
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
>> differently.
>
> I think there i
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
>>> all case.
>>
>> Yeah, we can choose not to pr
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 index
> scans, but some user
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 things this way, for what
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 parallel index build. It seems to me that p
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] proposed by Peter G. is using ab
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 be fetched/scanned from i
>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 many more cases. This pat
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 many more cases. This patch enables the parallelism for the
btree scans. Supporting p
87 matches
Mail list logo