Re: using index or check in ALTER TABLE SET NOT NULL - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: using index or check in ALTER TABLE SET NOT NULL
Date
Msg-id 370481511970756@web3j.yandex.ru
Whole thread Raw
In response to Re: using index or check in ALTER TABLE SET NOT NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: using index or check in ALTER TABLE SET NOT NULL  (Robert Haas <robertmhaas@gmail.com>)
Re: using index or check in ALTER TABLE SET NOT NULL  (Sergei Kornilov <sk@zsrv.org>)
Re: using index or check in ALTER TABLE SET NOT NULL  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Thanks all for reply!

Robert,

> Doing it based on an index scan doesn't necessarily seem like a good idea. We have
> no guarantee at all that the index scan will be faster than scanning
> the table would have been

I agree this. Thinking a little about idea of index scan i can not give reasonable usecase which required index. My
targetproblem of adding NOT NULL to big relation without long downtime can be done with ADD CONSTRAINT NOT VALID,
VALIDATEit in second transaction, then SET NOT NULL by my patch and drop unneeded constraint.
 

Stephen,

> Just, generally speaking, this is definitely something that I think we
> want and neither of the above concerns seem like they're technical
> reasons why we can't use something like this approach, just needs to
> perhaps be reworked to handle multiple columns in a single query.

I understood the idea, thank you.

Tom,

> I did not look at the patch yet, but TBH if it uses SPI for sub-operations
> of ALTER TABLE I think that is sufficient reason to reject it out of hand.

I understood, thank you.

So, i will soon delete SPI usage and index scan and post new simplified patch with verify data only by constraints.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL
Next
From: Stephen Frost
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL