Re: using index or check in ALTER TABLE SET NOT NULL
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>, ildar@adjust.com, Vitaly Burovoy <vitaly.burovoy@gmail.com>
Cc: sk@zsrv.org, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, i.musin@postgrespro.ru, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2018-11-22T17:04:55Z
Lists: pgsql-hackers
> On Tue, Nov 13, 2018 at 1:59 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > On 2018-Nov-13, Dmitry Dolgov wrote: > > > > On Sun, 4 Nov 2018 at 19:03, Sergei Kornilov <sk@zsrv.org> wrote: > > > > > > > If not properly cataloguing NOT NULL constraints would be fixed, can it > > > > potentially conflict with the current patch or not? > > > We already doing same stuff for "alter table attach partition" and in this patch i use exactly this routine. If proper cataloguing would conflict with my patch - it would conflict with "attach partition" validation too. > > > I think proper cataloguing can be implemented without conflict with proposed feature. > > > > Yes, indeed, this patch relies on the PartConstraintImpliedByRelConstraint. > > Then maybe it makes sense to go with the solution, proposed in this thread, > > while leaving open the possibility of having "SET NOT NULL NOT VALID"? From > > the functionality point of view it definitely would be beneficial. Any other > > opinions? > > I think we should ignore any SET NOT NULL NOT VALID patches, because > in practice they don't exist. Let's move forward with this, because the > optimization being proposed is clearly very useful. Absolutely agree. Looking at the history of the patch I see that it went through some extensive review and even was marked as Ready for Committer before the commentary from Peter, but since then some changes were made (rebase and code reorganization). Can someone from the reviewers confirm (or not) if the patch is in a good shape? If no, then I'll try to allocate some time for that, but can't promise any exact date.
Commits
-
Avoid using INFO elevel for what are fundamentally debug messages.
- db438318997b 13.0 landed
- 121e3ceed6d9 12.0 landed
-
Revert setting client_min_messages to 'debug1' in new tests.
- 5655565c077c 12.0 landed
-
Allow ALTER TABLE .. SET NOT NULL to skip provably unnecessary scans.
- bbb96c3704c0 12.0 landed
-
Improve predtest.c's internal docs, and enhance its functionality a bit.
- 5748f3a0aa7c 11.0 cited