Subject: Re: WIP: Covering + unique indexes.
To: Teodor Sigaev <teodor@sigaev.ru>
References: <56167F09.3090101@postgrespro.ru>
 <56BCBAE0.2080102@postgrespro.ru>
 <CAMkU=1zAr_jDAEk8QoxaMbGM=mdjbqGnhJqJzL+s1tVs5yREpQ@mail.gmail.com>
 <56D46114.9090205@postgrespro.ru> <56D5C970.6020002@postgrespro.ru>
 <56D5CCFC.1020507@postgrespro.ru>
 <CAB7nPqQa4HZ8QZaYB5zVWkYv6TFpBgY7QtemyRuJ2AJhbcNOUQ@mail.gmail.com>
 <56E6C35A.2050502@postgrespro.ru> <56EBF17E.2020702@pgmasters.net>
 <CAM3SWZS4nbTn=Ji=MOx5ft7Y9d+49x62N0xGadYav0BjfATUZA@mail.gmail.com>
 <56F0271D.5010004@postgrespro.ru>
 <CAM3SWZTfBosvae8Gh6AESRVKT3Fad7XcDkhZSbEqazZPE81rwQ@mail.gmail.com>
 <5703D236.1090907@postgrespro.ru>
 <CAM3SWZRheiMRFWmZ39X=G=w0WgZq5qqiyFAzCMg4jBpMPMsTJA@mail.gmail.com>
 <CAM3SWZQLLYajNy-5K702RTWMeRkUEEBtYJbb+ifYRQOCHNx6=A@mail.gmail.com>
 <57050BFE.7020805@postgrespro.ru>
 <CAM3SWZQZmo-Si1QGmmqwHTTOO22SNFVjLnjLB=adXBmrTGSRFg@mail.gmail.com>
 <CAM3SWZSBEqkTLYBvJYXjUcyt2BJLyBRWC2CmriZYGW9FwAxZHA@mail.gmail.com>
 <57079ED3.5000704@sigaev.ru> <5707A7FD.6080105@postgrespro.ru>
Cc: Peter Geoghegan <pg@heroku.com>, David Steele <david@pgmasters.net>,
 Michael Paquier <michael.paquier@gmail.com>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
 David Rowley <david.rowley@2ndquadrant.com>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Message-ID: <5707C8A0.1030208@postgrespro.ru>
Date: Fri, 8 Apr 2016 18:05:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <5707A7FD.6080105@postgrespro.ru>
Content-Type: multipart/mixed;
 boundary="------------060205000803030208080008"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

This is a multi-part message in MIME format.
--------------060205000803030208080008
Content-Type: text/plain; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 7bit

08.04.2016 15:45, Anastasia Lubennikova:
> 08.04.2016 15:06, Teodor Sigaev:
>>> On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>>> Personally, I like documenting assertions, and will sometimes write
>>>> assertions that the compiler could easily optimize away. Maybe going
>>>> *that* far is more a matter of personal style, but I think an
>>>> assertion about the new index tuple size being <= the old one is just
>>>> a good idea. It's not about a problem in your code at all.
>>>
>>> You should make index_truncate_tuple()/index_reform_tuple() promise to
>>> always do this in its comments/contract with caller as part of this,
>>> IMV.
>>>
>> Some notices:
>> - index_truncate_tuple(Relation idxrel, IndexTuple olditup, int 
>> indnatts,
>>                        int  indnkeyatts)
>>   Why we need indnatts/indnkeyatts? They are presented in idxrel struct
>>   already
>> - follow code where index_truncate_tuple() is called, it should never 
>> called in
>>   case where indnatts == indnkeyatts. So, indnkeyatts should be 
>> strictly less
>>   than indnatts, pls, change assertion. If they are equal the this 
>> function
>>   becomes complicated variant of CopyIndexTuple()
>
> Good point. These attributes seem to be there since previous versions 
> of the function.
> But now they are definitely unnecessary. Updated patch is attached

One more improvement - note about expressions into documentation.

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--------------060205000803030208080008
Content-Type: text/x-patch;
 name="including_docs_update.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="including_docs_update.patch"

diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index b5f67af..61a21a9 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -161,6 +161,8 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
         <literal>INCLUDING</> clause, which can slightly reduce the size of the index,
         due to storing included attributes only in leaf index pages.
         Currently, only the B-tree access method supports this feature.
+        Expressions as included columns are not supported since they cannot be used
+        in index-only scan.
        </para>
       </listitem>
      </varlistentry>

--------------060205000803030208080008
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--------------060205000803030208080008--