On Mon, May 27, 2019 at 4:44 PM Antonin Houska wrote:
> David Rowley wrote:
>
> > On Wed, 6 Mar 2019 at 12:54, David Rowley
> wrote:
> > > The latest patch is attached.
> >
> > Rebased version after pgindent run.
>
> I've spent some time looking into this.
>
> One problem I see is that SubLink
On Tue, Sep 03, 2019 at 01:13:43PM +1200, David Rowley wrote:
> Antonin, Thank you for the review. I will respond to it when I get
> time again.
It has been close to three months since this last update, so marked
the patch as returned with feedback.
--
Michael
signature.asc
Description: PGP
On Tue, 3 Sep 2019 at 09:21, Alvaro Herrera wrote:
> David, will we hear from you on this patch during this month?
> It sounds from Antonin's review that it needs a few changes.
Thanks for checking. I'm currently quite committed with things away
from the community and it's unlikely I'll get to
David, will we hear from you on this patch during this month?
It sounds from Antonin's review that it needs a few changes.
Thanks
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
David Rowley wrote:
> On Mon, 27 May 2019 at 20:43, Antonin Houska wrote:
> > I've spent some time looking into this.
>
> Thank you for having a look at this.
>
> > One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
> > not necessarily at the top of the join tree.
On Mon, 27 May 2019 at 20:43, Antonin Houska wrote:
> I've spent some time looking into this.
Thank you for having a look at this.
> One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
> not necessarily at the top of the join tree. Consider this example:
>
> CREATE
-
The big "IF" here is if we can calculate the size of the subplan to
know if it'll be hashed or not at the point in planning where this
conversion is done. I personally can't quite see how that'll work
reliably without actually planning the subquery, which I really doubt
On Fri, 14 Jun 2019 at 20:41, Simon Riggs wrote:
>
> On Wed, 6 Mar 2019 at 04:11, David Rowley
> wrote:
>>
>> Hi Jim,
>>
>> Thanks for replying here.
>>
>> On Wed, 6 Mar 2019 at 16:37, Jim Finnerty wrote:
>> >
>> > Actually, we're working hard to integrate the two approaches. I haven't
>> >
On Wed, 6 Mar 2019 at 04:11, David Rowley
wrote:
> Hi Jim,
>
> Thanks for replying here.
>
> On Wed, 6 Mar 2019 at 16:37, Jim Finnerty wrote:
> >
> > Actually, we're working hard to integrate the two approaches. I haven't
> had
> > time since I returned to review your patch, but I understand
Antonin Houska wrote:
> One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
> not necessarily at the top of the join tree. Consider this example:
>
> CREATE TABLE a(i int);
> CREATE TABLE b(j int);
> CREATE TABLE c(k int NOT NULL);
> CREATE TABLE d(l int);
>
> SELECT
David Rowley wrote:
> On Wed, 6 Mar 2019 at 12:54, David Rowley
> wrote:
> > The latest patch is attached.
>
> Rebased version after pgindent run.
I've spent some time looking into this.
One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
not necessarily at the top
On Wed, 6 Mar 2019 at 12:54, David Rowley wrote:
> The latest patch is attached.
Rebased version after pgindent run.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
not_in_anti_join_v1.4.patch
Description: Binary data
Hi Jim,
Thanks for replying here.
On Wed, 6 Mar 2019 at 16:37, Jim Finnerty wrote:
>
> Actually, we're working hard to integrate the two approaches. I haven't had
> time since I returned to review your patch, but I understand that you were
> checking for strict predicates as part of the
Way back in [1] I proposed that we allow NOT IN subqueries to be
converted into an anti-join where the subquery cannot return any NULL
values. As Tom pointed out to me, I had neglected to consider that
the outer side producing NULLs can cause the anti-join plan to produce
incorrect results. The
14 matches
Mail list logo
