From: | Hywel Carver <hywel(at)skillerwhale(dot)com> |
---|---|
To: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
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-01 22:56:37 |
Message-ID: | CAFcA2FauZ2jGka8utvFmRE1eLrKfmJmPnQjtf_cdewChFu0qcQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 30, 2021 at 12:21 PM Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
wrote:
> On 12/3/21 12:05, Hywel Carver wrote:
> > I've built and tested this, and it seems to function correctly to me.
> One question I have is whether the added "IS NOT NULL" filters can be
> omitted when they're unnecessary. Some of the resulting plans included an
> "IS NOT NULL" filter on a non-nullable column. To be clear, this is still
> an improvement (to me) without that.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-07-01 23:50:25 | Re: PG 14 release notes, first draft |
Previous Message | Thomas Munro | 2021-07-01 22:09:39 | Re: A qsort template |