Re: using index or check in ALTER TABLE SET NOT NULL

From: Sergei Kornilov <sk(at)zsrv(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: using index or check in ALTER TABLE SET NOT NULL
Date: 2017-11-29 15:52:36
Message-ID: 370481511970756@web3j.yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 target problem of adding NOT NULL to big relation without long downtime can be done with ADD CONSTRAINT NOT VALID, VALIDATE it 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-11-29 15:58:12 Re: using index or check in ALTER TABLE SET NOT NULL
Previous Message Tom Lane 2017-11-29 15:47:21 Re: using index or check in ALTER TABLE SET NOT NULL