On Wed, Sep 9, 2020 at 10:20 AM Amit Kapila wrote:
>
> On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila wrote:
> >
> > On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> > > >
> > > > I still don't agree with this as proposed.
>
On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila wrote:
>
> On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila wrote:
> >
> > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> > >
> > > I still don't agree with this as proposed.
> > >
> > > + * For now, we don't allow parallel inserts of any form not
On Tue, Aug 18, 2020 at 1:37 PM Bharath Rupireddy
wrote:
>
> On Tue, Jul 14, 2020 at 1:20 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila wrote:
> >
> > > I think we can do more than this by
> > > parallelizing the Insert part of this query as well as we have lifted
>
On Tue, Jul 14, 2020 at 1:20 PM Dilip Kumar wrote:
>
> On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila wrote:
>
> > I think we can do more than this by
> > parallelizing the Insert part of this query as well as we have lifted
> > group locking restrictions related to RelationExtension and Page lock
On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila wrote:
>
> On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> >
> > I still don't agree with this as proposed.
> >
> > + * For now, we don't allow parallel inserts of any form not even where the
> > + * leader can perform the insert. This
On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
>
> I still don't agree with this as proposed.
>
> + * For now, we don't allow parallel inserts of any form not even where the
> + * leader can perform the insert. This restriction can be uplifted once
> + * we allow the planner to generate
On Sun, Jul 26, 2020 at 7:24 AM Amit Kapila wrote:
> No, "git diff --check" doesn't help. I have tried pgindent but that
> also doesn't help neither was I expecting it to help. I am still not
> able to figure out how I goofed up this but will spend some more time
> on this. In the meantime, I
On Sun, Jul 26, 2020 at 4:54 PM Amit Kapila wrote:
>
> On Sat, Jul 25, 2020 at 8:42 PM Tom Lane wrote:
> >
>
> No, "git diff --check" doesn't help. I have tried pgindent but that
> also doesn't help neither was I expecting it to help. I am still not
> able to figure out how I goofed up this
On Sat, Jul 25, 2020 at 8:42 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Jul 24, 2020 at 7:36 PM Tom Lane wrote:
> >> Yeah, the proposed comment changes don't actually add much. Also
> >> please try to avoid inserting non-ASCII into the source code;
> >> at least in my mail reader,
Amit Kapila writes:
> On Fri, Jul 24, 2020 at 7:36 PM Tom Lane wrote:
>> Yeah, the proposed comment changes don't actually add much. Also
>> please try to avoid inserting non-ASCII into the source code;
>> at least in my mail reader, that attachment has some.
> I don't see any non-ASCII
On Fri, Jul 24, 2020 at 7:36 PM Tom Lane wrote:
>
> Robert Haas writes:
> > Well, I think the comments could be more clear - for the insert case
> > specifically - about which cases you think are and are not safe.
>
Okay, I'll update the patch accordingly.
> Yeah, the proposed comment changes
Robert Haas writes:
> Well, I think the comments could be more clear - for the insert case
> specifically - about which cases you think are and are not safe.
Yeah, the proposed comment changes don't actually add much. Also
please try to avoid inserting non-ASCII into the source code;
at least
On Fri, Jul 24, 2020 at 7:59 AM Amit Kapila wrote:
> On Fri, Jul 17, 2020 at 11:24 AM Amit Kapila wrote:
> > Do you have something else in mind?
>
> I am planning to commit the comments change patch attached in the
> above email [1] next week sometime (probably Monday or Tuesday) unless
> you
On Fri, Jul 17, 2020 at 11:24 AM Amit Kapila wrote:
>
> Do you have something else in mind?
>
I am planning to commit the comments change patch attached in the
above email [1] next week sometime (probably Monday or Tuesday) unless
you have something more to add?
[1] -
On Thu, Jul 16, 2020 at 6:43 PM Robert Haas wrote:
>
> On Wed, Jul 15, 2020 at 11:14 PM Amit Kapila wrote:
> > The attached patch fixes the comments. Let me know if you think I
> > have missed anything or any other comments.
>
> If it's safe now, why not remove the error check?
>
I think it is
On Wed, Jul 15, 2020 at 11:14 PM Amit Kapila wrote:
> The attached patch fixes the comments. Let me know if you think I
> have missed anything or any other comments.
If it's safe now, why not remove the error check?
(Is it safe? Could there be other problems?)
--
Robert Haas
EnterpriseDB:
On Thu, Jul 16, 2020 at 8:44 AM Amit Kapila wrote:
>
> On Wed, Jul 15, 2020 at 8:06 AM Amit Kapila wrote:
> >
> > On Wed, Jul 15, 2020 at 12:32 AM Robert Haas wrote:
> > >
> > > On Sat, Jul 11, 2020 at 8:37 AM Dilip Kumar wrote:
> > > > I have just notice that the parallelism is off even for
On Wed, Jul 15, 2020 at 8:06 AM Amit Kapila wrote:
>
> On Wed, Jul 15, 2020 at 12:32 AM Robert Haas wrote:
> >
> > On Sat, Jul 11, 2020 at 8:37 AM Dilip Kumar wrote:
> > > I have just notice that the parallelism is off even for the select
> > > part of the query mentioned in the $subject. I
On Sat, Jul 11, 2020 at 8:37 AM Dilip Kumar wrote:
> I have just notice that the parallelism is off even for the select
> part of the query mentioned in the $subject. I see the only reason it
> is not getting parallel because we block the parallelism if the query
> type is not SELECT. I don't
On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar wrote:
> I have just notice that the parallelism is off even for the select
> part of the query mentioned in the $subject. I see the only reason it
> is not getting parallel because we block the parallelism if the query
> type is not SELECT. I don't
On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila wrote:
>
> On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar wrote:
> >
> > I have just notice that the parallelism is off even for the select
> > part of the query mentioned in the $subject. I see the only reason it
> > is not getting parallel because we
On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar wrote:
>
> I have just notice that the parallelism is off even for the select
> part of the query mentioned in the $subject. I see the only reason it
> is not getting parallel because we block the parallelism if the query
> type is not SELECT. I don't
I have just notice that the parallelism is off even for the select
part of the query mentioned in the $subject. I see the only reason it
is not getting parallel because we block the parallelism if the query
type is not SELECT. I don't see any reason for not selecting the
parallelism for this
23 matches
Mail list logo
