| From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PROPOSAL] Covering + unique indexes. |
| Date: | 2015-09-15 11:51:56 |
| Message-ID: | CAP-rdTbiYt+sgWoNc10boJmwU7qmZto20Larzv3LZ4iB3Mv3MQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2015-09-15 David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>:
> I'm also a bit confused where f3 comes in here. If it's UNIQUE on (f1,f2)
> and we include f4. Where's f3?
Columns f1, f2, f3 are in the internal nodes of the tree (i.e., they
are used to find the ultimate leaf nodes). f4 is only in the leaf
nodes. If f4 are typically big values, and they are typically not used
in the search predicate, it makes the upper part of the index (which
determines how many levels the index has) larger for no good reason.
f4 can still be retrieved without going to the heap, so including it
in the leaf nodes makes it possible to do index-only scans more often.
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sameer Thakur-2 | 2015-09-15 12:02:13 | Re: Support for N synchronous standby servers - take 2 |
| Previous Message | Vik Fearing | 2015-09-15 11:24:47 | Re: [PROPOSAL] Covering + unique indexes. |