Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX" - Mailing list pgsql-hackers

From Vitaly Burovoy
Subject Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"
Date
Msg-id CAKOSWN=MaMAJF-o_LJei_stE3_KOJxocfWaNyc7C0sKML-RfBw@mail.gmail.com
Whole thread Raw
In response to Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 1/8/16, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 8 January 2016 at 12:49, Vitaly Burovoy <vitaly.burovoy@gmail.com>
> wrote:
>
>
>> In Postgres9.1 a new feature was implemented [1] for adding PK and
>> UNIQUE constraints using indexes created concurrently, but constraints
>> NOT NULL and CHECK still require full seqscan of a table. New CHECK
>> constraint allows "NOT VALID" option but VALIDATE CONSTRAINT still
>> does seqscan (with RowExclusiveLock, but for big and constantly
>> updatable table it is still awful).
>>
>> It is possible to find wrong rows in a table without seqscan if there
>> is an index with a predicate allows to find such rows. There is no
>> sense what columns it has since it is enough to check whether
>> index_getnext for it returns NULL (table is OK) or any tuple (table
>> has wrong rows).
>>
>
> You avoid a full seqscan by creating an index which also does a full seq
> scan.
>
> How does this help? The lock and scan times are the same.
>
> --
> Simon Riggs                http://www.2ndQuadrant.com/
> <http://www.2ndquadrant.com/>
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

I avoid not a full seqscan, but a time when table is under
ExclusiveLock: index can be build concurrently without locking table.

-- 
Best regards,
Vitaly Burovoy



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!
Next
From: Simon Riggs
Date:
Subject: Re: New feature "... ALTER CONSTRAINT ... VERIFY USING INDEX"