Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eK4fJ-0005sf-3m for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Nov 2017 15:52:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eK4fI-0006Ux-6k for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Nov 2017 15:52:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eK4fH-0006Un-RR for pgsql-hackers@lists.postgresql.org; Wed, 29 Nov 2017 15:52:48 +0000 Received: from forward3j.cmail.yandex.net ([2a02:6b8:0:1630::16]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eK4fD-0006hU-V1 for pgsql-hackers@postgresql.org; Wed, 29 Nov 2017 15:52:46 +0000 Received: from mxback10j.mail.yandex.net (mxback10j.mail.yandex.net [IPv6:2a02:6b8:0:1619::113]) by forward3j.cmail.yandex.net (Yandex) with ESMTP id CDC9920C99; Wed, 29 Nov 2017 18:52:38 +0300 (MSK) Received: from web3j.yandex.ru (web3j.yandex.ru [2a02:6b8:0:1619::303]) by mxback10j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id vtC0TlFZru-qaFaTf1L; Wed, 29 Nov 2017 18:52:37 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zsrv.org; s=mail; t=1511970757; bh=W5/Wf5j5WD17jsE51qiOP893dI5Lts+/vZgV3CtHd0Q=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date; b=ckY/t3DUIzdufHhNz2CRYFOlSavXfxZpg7rI7B8NoEXa7Vh4b4pVes19LQOrn+8Qq 6fDcUsnUkSAWxKeLJoP7q+0AhqSqNqlz9QzGD47LcBHMmqnLIc2l10vGiBm+6hn9Qz umqMzZ27Tpk0oPBevfueOlVUSv4GB7Q9tnCjqgrI= Authentication-Results: mxback10j.mail.yandex.net; dkim=pass header.i=@zsrv.org Received: by web3j.yandex.ru with HTTP; Wed, 29 Nov 2017 18:52:36 +0300 From: Sergei Kornilov To: Tom Lane , Stephen Frost Cc: Robert Haas , "pgsql-hackers@postgresql.org" In-Reply-To: <9878.1511970441@sss.pgh.pa.us> References: <81911511895540@web58j.yandex.ru> <20171129152135.GN4628@tamriel.snowman.net> <9878.1511970441@sss.pgh.pa.us> Subject: Re: using index or check in ALTER TABLE SET NOT NULL MIME-Version: 1.0 Message-Id: <370481511970756@web3j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 29 Nov 2017 18:52:36 +0300 Content-Transfer-Encoding: 7bit Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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.