Re: NOT IN subquery optimization

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Li, Zheng" <zhelli(at)amazon(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Richard Guo <riguo(at)pivotal(dot)io>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com>
Subject: Re: NOT IN subquery optimization
Date: 2019-03-02 13:34:20
Message-ID: CAKJS1f_+JQx581EJCeZvfL0vP_hg_Q1xXmpVbfkEES9Z5KraXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2 Mar 2019 at 13:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > I think you're fighting a losing battle here with adding OR quals to
> > the join condition.
>
> Yeah --- that has a nontrivial risk of making things significantly worse,
> which makes it a hard sell. I think the most reasonable bet here is
> simply to not perform the transformation if we can't prove the inner side
> NOT NULL. That's going to catch most of the useful cases anyway IMO.

Did you mean outer side NOT NULL? The OR col IS NULL was trying to
solve the outer side nullability problem when the inner side is empty.
Of course, the inner side needs to not produce NULLs either, but
that's due to the fact that if a NULL exists in the inner side then
the anti-join should not produce any records.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Perumal Raj 2019-03-02 14:23:25 Re: Question about pg_upgrade from 9.2 to X.X
Previous Message David Rowley 2019-03-02 13:01:50 Re: [HACKERS] PATCH: multivariate histograms and MCV lists