From: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Hywel Carver <hywel(at)skillerwhale(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Konstantin Knizhnik <knizhnik(at)garret(dot)ru> |
Subject: | Re: Removing unneeded self joins |
Date: | 2021-07-05 13:20:01 |
Message-ID: | 4b69ea09-5047-cd8a-a0d7-de1f12120433@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/7/21 01:56, Hywel Carver wrote:
> On Wed, Jun 30, 2021 at 12:21 PM Andrey Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru <mailto:a(dot)lepikhov(at)postgrespro(dot)ru>> wrote:
> I think, here we could ask more general question: do we want to
> remove a
> 'IS NOT NULL' clause from the clause list if the rest of the list
> implicitly implies it?
>
>
> My suggestion was not to remove it, but to avoid adding it in the first
> place. When your optimisation has found a join on a group of columns
> under a uniqueness constraint, you would do something like this (forgive
> the pseudo-code)
>
> foreach(column, join_clause) {
> if(column.nullable) { // This condition is what I'm suggesting is added
> add_null_test(column, IS_NOT_NULL);
> }
> }
>
> But it may be that that's not possible or practical at this point in the
> code.
I think, such option will require to implement a new machinery to prove
that arbitrary column couldn't produce NULL value.
--
regards,
Andrey Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-07-05 13:48:52 | Re: Removed extra memory allocations from create_list_bounds |
Previous Message | Anastasia Lubennikova | 2021-07-05 12:49:09 | Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb |