On Tue, Mar 15, 2016 at 5:22 AM, Robert Haas wrote:
>
> On Sat, Mar 12, 2016 at 1:58 AM, Amit Kapila
wrote:
> > Yeah, that makes the addition of test for this functionality difficult.
> > Robert, do you have any idea what kind of test would have caught this
issue?
>
> Yep. Committed with that te
On Sat, Mar 12, 2016 at 1:58 AM, Amit Kapila wrote:
> Yeah, that makes the addition of test for this functionality difficult.
> Robert, do you have any idea what kind of test would have caught this issue?
Yep. Committed with that test:
DO $$
BEGIN
EXECUTE 'EXPLAIN ANALYZE SELECT * INTO T
On Sat, Mar 12, 2016 at 7:11 PM, Mithun Cy
wrote:
>
>
>
> On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila
wrote:
> >With force_parallel_mode=on, I could see many other failures as well. I
think it is better to have test, which tests this functionality with
>force_parallel_mode=regress
>
> as per us
Sorry there was some issue with my mail settings same mail got set more
than once.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila
wrote:
>With force_parallel_mode=on, I could see many other failures as well. I
think it is better to have test, which tests this functionality with
>force_parallel_mode=regress
as per user manual.
Setting this value to regress has all of the same eff
On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila
wrote:
>With force_parallel_mode=on, I could see many other failures as well. I
think it is better to have test, which tests this functionality with
>force_parallel_mode=regress
as per user manual.
Setting this value to regress has all of the same eff
On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila
wrote:
>With force_parallel_mode=on, I could see many other failures as well. I
think it is better to have test, which tests this functionality with
>force_parallel_mode=regress
as per user manual.
Setting this value to regress has all of the same eff
On Sat, Mar 12, 2016 at 2:02 PM, Mithun Cy
wrote:
>
>
>
> On Sat, Mar 12, 2016 at 12:28 PM, Amit Kapila
wrote
> >I don't see how this test will fail with force_parallel_mode=regress and
max_parallel_degree > 0 even without the patch proposed to fix the issue in
>hand. In short, I don't think thi
On Sat, Mar 12, 2016 at 12:28 PM, Amit Kapila
wrote
>I don't see how this test will fail with force_parallel_mode=regress and
max_parallel_degree > 0 even without the patch proposed to fix the issue in
>hand. In short, I don't think this test would have caught the issue, so I
don't see much advan
On Fri, Mar 11, 2016 at 3:34 PM, Mithun Cy
wrote:
>
> On Thu, Mar 10, 2016 at 9:39 PM, Robert Haas
wrote:
> >I guess there must not be an occurrence of this pattern in the
> >regression tests, or previous force_parallel_mode testing would have
> >found this problem. Perhaps this patch should add
On Thu, Mar 10, 2016 at 9:39 PM, Robert Haas wrote:
>I guess there must not be an occurrence of this pattern in the
>regression tests, or previous force_parallel_mode testing would have
>found this problem. Perhaps this patch should add one?
I have added the test to select_into.sql. Added Explai
On Thu, Mar 10, 2016 at 4:43 AM, Amit Kapila wrote:
> There should be a white space between 0:CURSOR_OPT_PARALLEL_OK. Also I
> don't see this comment is required as similar other usage doesn't have any
> such comment. Fixed these two points in the attached patch.
>
> In general, the patch looks
On Wed, Mar 9, 2016 at 8:18 PM, Mithun Cy
wrote:
>
> Hi All,
>
> Explain [Analyze] Select Into table. produces the plan which uses
parallel scans.
>
> Possible Fix:
>
> I tried to make a patch to fix this. Now in ExplainOneQuery if into
clause is
>
> defined then parallel plans are disabled as
Hi All,
Explain [Analyze] Select Into table. produces the plan which uses
parallel scans.
*Test:*
create table table1 (n int);
insert into table1 values (generate_series(1,500));
analyze table1;
set parallel_tuple_cost=0;
set max_parallel_degree=3;
postgres=# explain select into table
14 matches
Mail list logo
