Re: WIP: Covering + unique indexes.

Teodor Sigaev <teodor@sigaev.ru>

From: Teodor Sigaev <teodor@sigaev.ru>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Amit Kapila <amit.kapila16@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, Andrey Borodin <amborodin@acm.org>, pgsql-hackers <pgsql-hackers@postgresql.org>, Anastasia Lubennikova <lubennikovaav@gmail.com>, Brad DeJong <Brad.Dejong@infor.com>
Date: 2017-03-30T15:25:38Z
Lists: pgsql-hackers
>> -	IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P
>> +	IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P INCLUDE
> I think your syntax would read no worse, possibly even better, if you
> just used the existing INCLUDING keyword.
It was a discussion in this thread about naming and both databases, which 
support covering indexes, use INCLUDE keyword.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/


Commits

  1. Adjust INCLUDE index truncation comments and code.

  2. Add commentary explaining why MaxIndexTuplesPerPage calculation is safe.

  3. Indexes with INCLUDE columns and their support in B-tree

  4. Add amcheck verification of heap relations belonging to btree indexes.

  5. Doc: move info for btree opclass implementors into main documentation.

  6. Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

  7. Remove dedicated B-tree root-split record types.

  8. Restructure index access method API to hide most of it at the C level.

  9. Split _bt_insertonpg to two functions.

  10. Major overhaul of btree index code. Eliminate special BTP_CHAIN logic for