From: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> |
---|---|
To: | siracusa(at)mindspring(dot)com, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Indexes and sorting |
Date: | 2004-02-06 19:23:24 |
Message-ID: | 4023E9AC.6010407@zara.6.isreserved.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
John Siracusa wrote:
> SELECT * FROM t WHERE a = 1 AND b = 2 AND c = 3 ORDER BY b;
>
> Let's say the table just has one index:
>
> CREATE INDEX b_idx ON t (b);
>
> In this case, obviously the b_idx will be used and no sorting after the fact
> will be required. Now let's add an index:
>
> CREATE INDEX key_idx ON t (a, b, c);
>
> On the same query, now the key_idx will be used and there'll be a sort
> wrapped around it all. The question is, is the b_idx useful at all anymore?
> Can it be used to speed up the sort step? If so, how? If not, why not?
I believe that if you want to do ORDER BY b, then INDEX ON t(b) is
needed. Or ON t(b,c). If you want to ORDER BY a, then either INDEX ON
t(a) or ON t(a,b,c) or ON t(a,c) etc. is needed. See the manual on
CREATE INDEX for more details.
--
dave
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2004-02-06 19:27:27 | Re: Run 2 versions of Postgresql on one machine? |
Previous Message | David Garamond | 2004-02-06 19:19:23 | Re: PL/Ruby |