| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Fuhr <mike(at)fuhr(dot)org> |
| Cc: | Tom Laudeman <twl8n(at)virginia(dot)edu>, Reece Hart <reece(at)harts(dot)net>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Tuning to speed select |
| Date: | 2006-08-10 15:54:23 |
| Message-ID: | 16115.1155225263@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> Excerpt from the 8.1 Release Notes:
> * Allow nonconsecutive index columns to be used in a multicolumn
> index (Tom)
> For example, this allows an index on columns a,b,c to be used in
> a query with WHERE a = 4 and c = 10.
> If you're querying only on c then an index on (a,b,c) will probably
> be slower than an index on (c), but if you have only (a,b,c) then
> the planner will consider using it.
Note that if your query doesn't have a constraint on the first index
column, it's unlikely that that index will get chosen, because the
entire index would have to be scanned. Before 8.1 it was guaranteed
not to be chosen.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Harpreet Dhaliwal | 2006-08-10 15:57:14 | Re: Connection string |
| Previous Message | Michael Fuhr | 2006-08-10 15:34:52 | Re: Tuning to speed select |