| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Covering Indexes |
| Date: | 2012-07-17 17:13:07 |
| Message-ID: | 12966.1342545187@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"David E. Wheeler" <david(at)justatheory(dot)com> <CA+U5nMJz33ZsvqPzK-AUoindxkQ6eLiP1HgQ53byoDLpwfDWUA(at)mail(dot)gmail(dot)com> writes:
> On Jul 17, 2012, at 5:32 PM, Simon Riggs wrote:
>> The phrase "unindexed" seems misleading since the data is clearly in
>> the index from the description on the URL you gave. And since the
>> index is non-unique, I don't see any gap between Postgres and
>> SQLliite4.
> Yeah, but that index is unnecessarily big if one will never use c or d
> in the search.
The data would still have to be stored in the leaf entries, at least.
Yeah, you could possibly omit the "unindexed columns" from upper tree
levels, but with typical btree fanout ratios in the hundreds, the
overall space savings would be negligible. The idea of different index
tuple descriptors on different tree levels doesn't appeal to me, either.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-07-17 17:26:43 | Re: CompactCheckpointerRequestQueue versus pad bytes |
| Previous Message | Andrew Dunstan | 2012-07-17 17:01:34 | Re: Covering Indexes |