Re: Covering Indexes - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Covering Indexes
Date
Msg-id 4FEC7D46.40306@dunslane.net
Whole thread Raw
In response to Re: Covering Indexes  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Covering Indexes
List pgsql-hackers

On 06/28/2012 11:37 AM, Jeff Janes wrote:
> On Thu, Jun 28, 2012 at 5:16 AM, David E. Wheeler<david@justatheory.com>  wrote:
>> Hackers,
>>
>> Very interesting design document for SQLite 4:
>>
>>   http://www.sqlite.org/src4/doc/trunk/www/design.wiki
>>
>> I'm particularly intrigued by "covering indexes". For example:
>>
>>     CREATE INDEX cover1 ON table1(a,b) COVERING(c,d);
> I don't see the virtue of this in this case.  Since the index is not
> unique, why not just put the index on (a,b,c,d) and be done with it?
> Is there some advantage to be had in inventing a way to store c and d
> in the index without having them usable for indexing?
>

Presumably the comparison function will be faster the fewer attributes 
it needs to compare.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [v9.3] Row-Level Security
Next
From: Robert Haas
Date:
Subject: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes