Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1etDiM-0002lZ-0o for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Mar 2018 14:37:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1etDiK-0002E6-Qj for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Mar 2018 14:37:12 +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.89) (envelope-from ) id 1etDiK-0002Dw-B4 for pgsql-hackers@lists.postgresql.org; Tue, 06 Mar 2018 14:37:12 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1etDiG-0000qR-Pc for pgsql-hackers@postgresql.org; Tue, 06 Mar 2018 14:37:11 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id D0BAA21C1E35; Tue, 6 Mar 2018 17:37:06 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.109] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 5615221C1C46; Tue, 6 Mar 2018 17:37:06 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1520347026; bh=AU2z0s5MSqlCVLqybvZdvHvkrnz2eVBlk4p1uCT/lkM=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=MwjQ/wL9XbZ/epn4islt1CRWtu6HHddbjSlbo+APAfhrTdSdHsnZM5es7758/aXl0 giSEHE2eduKw8U0t96fMo64WklrQxREkV2N/34MwcqjKxKOf3waFWIbZwdq7pGMkln Cm9TnA4DnAGcGutnQwRnb4Q1UMdNirL4zatpFALw= Subject: Re: using index or check in ALTER TABLE SET NOT NULL To: Sergei Kornilov , Stephen Frost References: <81911511895540@web58j.yandex.ru> <20171129152135.GN4628@tamriel.snowman.net> <9878.1511970441@sss.pgh.pa.us> <370481511970756@web3j.yandex.ru> <491651511974381@web27j.yandex.ru> <369811512396584@web6o.yandex.ru> <20180123153711.GI2416@tamriel.snowman.net> <354171516734367@web46g.yandex.ru> <8fd20248-4059-4d46-b33f-c9760cb3ddb9@postgrespro.ru> <611431520341951@web57o.yandex.ru> Cc: Robert Haas , Tom Lane , "pgsql-hackers@postgresql.org" From: Ildar Musin Message-ID: <7a6a8eb5-a36c-239a-1724-9fc8a2f29115@postgrespro.ru> Date: Tue, 6 Mar 2018 17:37:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <611431520341951@web57o.yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 06.03.2018 16:12, Sergei Kornilov wrote: > Hello thank you for review! > >> Adding check constraint will also force the full table scan. So I >> think it would be better to rephrased it as follows: > Agree. I updated docs in new attached patch slightly different > >> Regarding regression tests it may be useful to set >> client_min_messages to 'debug1' before setting "NOT NULL" attribute >> for a column. In this case you can tell for sure that >> NotNullImpliedByRelConstraints() returned true (i.e. your code >> actually did the job) as the special debug message is printed to >> the log. > I can not find any debug messages in tests: grep client_min_messages > -irn src/test/ Only some warning level and few error. So i verify in > regression tests only top-level behavior. Or this paragraph was for > other people, not for tests? > Sorry, probably I didn't explain it clearly enough. I meant that your regression tests can't distinguish cases when the full table scan was actually performed from the ones when it was skipped due to NotNullImpliedByRelConstraints() check. For instance, consider this piece from the test suite: # create table atacc1 (test_a int, test_b int); CREATE TABLE ... # alter table atacc1 add constraint atacc1_constr_a_valid check(test_a is not null); ALTER TABLE # alter table atacc1 alter test_a set not null; ALTER TABLE It is not obvious that full table scan was omitted. But if we set client_min_messages to 'debug1', we'll be able to see what is really happened by the different debug messages. For example: # create table atacc1 (test_a int, test_b int); CREATE TABLE ... # set client_min_messages to 'debug1'; SET # alter table atacc1 alter test_a set not null; DEBUG: verifying table "atacc1" <<<< full table scan! ALTER TABLE # alter table atacc1 alter test_a drop not null; ALTER TABLE # alter table atacc1 add constraint atacc1_constr_a_valid check(test_a is not null); DEBUG: verifying table "atacc1" ALTER TABLE # alter table atacc1 alter test_a set not null; DEBUG: verifying table "atacc1" NOT NULL constraint on test_a attribute by existed constraints <<<< full scan was skipped! ALTER TABLE -- Ildar Musin i.musin@postgrespro.ru