From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Covering Indexes |
Date: | 2012-06-28 15:50:30 |
Message-ID: | 4FEC7D46.40306@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)justatheory(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-06-28 16:01:10 | Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes |
Previous Message | Tom Lane | 2012-06-28 15:46:50 | Re: [v9.3] Row-Level Security |