David Rowley writes:
> On Thu, 27 Feb 2025 at 14:55, Tom Lane wrote:
>> But I think having NOT NULL info available earlier might allow
>> removal of some nasty kluges (I'm looking at you,
>> restriction_is_always_true).
> Can you elaborate on the gripe here, or point to the thread where you have
On Thu, 27 Feb 2025 at 14:55, Tom Lane wrote:
> But I think having NOT NULL info available earlier might allow
> removal of some nasty kluges (I'm looking at you,
> restriction_is_always_true).
Can you elaborate on the gripe here, or point to the thread where you have?
David
Robert Haas writes:
> On Wed, Feb 26, 2025 at 4:58 PM Tom Lane wrote:
>> Yeah. The key problem blocking doing something about it in the
>> planner is that at the time we want to do join tree restructuring,
>> we haven't yet collected the per-relation data that would allow
>> us to know about NOT
On Wed, Feb 26, 2025 at 4:58 PM Tom Lane wrote:
> Yeah. The key problem blocking doing something about it in the
> planner is that at the time we want to do join tree restructuring,
> we haven't yet collected the per-relation data that would allow
> us to know about NOT NULL constraints, nor run
Robert Haas writes:
> I'm not quite sure, either. I think that the first option (proving
> that there can be no NULL values) is probably more similar to
> thingswe've done elsewhere in the planner, so I think I have been
> assuming that if we did something about this, it would be that.
Yeah. The
On Wed, Feb 26, 2025 at 4:46 AM Richard Guo wrote:
> I agree that it'd be beneficial to make some improvements to NOT IN
> subqueries. From what I can see, we may have two potential options:
>
> * As Tom mentioned, we can prove that the subquery's output never
> contains NULL values and then conv
On Wed, 2025-02-26 at 18:08 +0800, Tender Wang wrote:
> Recently, I found Greenplum implement pull-up NOT IN subquery.
> They have the below comments in their codes:
>
> We normalize NOT subqueries using the following axioms:
> *
> * val NOT IN (subq) => val <> ALL (subq)
That is true, but I
Richard Guo 于2025年2月26日周三 17:46写道：
> On Tue, Feb 25, 2025 at 1:30 AM Robert Haas wrote:
> > On Mon, Feb 24, 2025 at 8:08 AM wenhui qiu
> wrote:
> > > Actually ,Many fork postgresql databases have already implemented
> ,For example, if the relevant field has a non-null constraint ，Many
> dat
On Tue, Feb 25, 2025 at 1:30 AM Robert Haas wrote:
> On Mon, Feb 24, 2025 at 8:08 AM wenhui qiu wrote:
> > Actually ,Many fork postgresql databases have already implemented ,For
> > example, if the relevant field has a non-null constraint ，Many databases
> > can do the same thing as not exi
On Mon, Feb 24, 2025 at 8:08 AM wenhui qiu wrote:
> Actually ,Many fork postgresql databases have already implemented ,For
> example, if the relevant field has a non-null constraint ，Many databases can
> do the same thing as not exist （ MySQL ，SQL Server，Oracle）
I'm not surprised to hear it
Hi Laurenz
Actually ,Many fork postgresql databases have already implemented ,For
example, if the relevant field has a non-null constraint ，Many databases
can do the same thing as not exist （ MySQL ，SQL Server，Oracle）
Thanks
On Mon, Feb 24, 2025 at 7:55 PM Laurenz Albe
wrote:
> On Mon, 202
On Mon, 2025-02-24 at 17:12 +0800, wenhui qiu wrote:
> Do we have plans for NOT IN subquery pull up?
As mentioned before, that is not possible.
Best practice is to avoid NOT IN with subqueries altogether.
The result is usually not what people expect it to be.
Yours,
Laurenz Albe
--
*E-Mail D
wenhui qiu writes:
>I found this path https://commitfest.postgresql.org/patch/3235/ already
> supports anti join , But I've found that in many cases it doesn't work.It
> always uses SubPlan Here's my testing process.
NOT IN is not convertible to an anti-join: the semantics are wrong
because o
wenhui qiu 于2025年2月24日周一 09:48写道：
> Hi Richard Guo
>I found this path https://commitfest.postgresql.org/patch/3235/
> already supports anti join , But I've found that in many cases it doesn't
> work.It always uses SubPlan Here's my testing process.
>
> ###
> create table join1 (id int
Hi Richard Guo
I found this path https://commitfest.postgresql.org/patch/3235/ already
supports anti join , But I've found that in many cases it doesn't work.It
always uses SubPlan Here's my testing process.
###
create table join1 (id integer,name varchar(300),k1 integer);
create table
15 matches
Mail list logo
