| From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
|---|---|
| To: | Tomasz Myrta <jasiek(at)klaster(dot)net> |
| Cc: | Rigmor Ukuhe <rigmor(dot)ukuhe(at)finestmedia(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: "Overlaping" indexes |
| Date: | 2004-02-02 18:58:49 |
| Message-ID: | Pine.LNX.4.33.0402021155530.19831-100000@css120.ihs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, 2 Feb 2004, Tomasz Myrta wrote:
> Dnia 2004-02-02 19:30, U¿ytkownik scott.marlowe napisa³:
> > Not entirely, since it only has to sort two columns, it will be smaller,
> > and will therefore be somewhat faster.
>
> Can you say something more about it? Will it be enough faster to keep
> them both? Did anyone make such tests?
that really depends on the distribution of the third column. If there's
only a couple of values in the third column, no big deal. If each entry
is unique, and it's a large table, very big deal.
It is only useful to have a three column index if you actually use it. If
you have an index on (a,b,c) and select order by b, the index won't get
used unless the a part is in the where clause.
the other issue is updates. IT WILL cost more to update two indexes
rather than one. Generally, you can drop / readd the index and use
explain analyze on one of your own queries to see if that helps.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Barnard | 2004-02-02 19:14:15 | Increasing number of PG connections. |
| Previous Message | Tomasz Myrta | 2004-02-02 18:43:03 | Re: "Overlaping" indexes |