From: | Ildar Musin <i(dot)musin(at)postgrespro(dot)ru> |
---|---|
To: | Sergei Kornilov <sk(at)zsrv(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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: | 2018-03-06 14:37:06 |
Message-ID: | 7a6a8eb5-a36c-239a-1724-9fc8a2f29115@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(dot)musin(at)postgrespro(dot)ru
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-03-06 14:44:31 | Re: Re: Boolean partitions syntax |
Previous Message | David Steele | 2018-03-06 14:30:49 | Re: Re: [HACKERS] [PATCH] kNN for SP-GiST |