| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Covering Indexes |
| Date: | 2012-06-28 15:37:55 |
| Message-ID: | CAMkU=1yDHXMw_8SKA-O=tLbiMbMKmwYedE=pBhM7KDoB+cp+eg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-06-28 15:46:50 | Re: [v9.3] Row-Level Security |
| Previous Message | Florian Pflug | 2012-06-28 15:34:13 | Re: [v9.3] Row-Level Security |