| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Ben <bench(at)silentmedia(dot)com> | 
| Cc: | Bill Moran <wmoran(at)collaborativefusion(dot)com>, pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: quickly getting the top N rows | 
| Date: | 2007-10-04 18:52:10 | 
| Message-ID: | 3785.1191523930@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Ben <bench(at)silentmedia(dot)com> writes:
> No, the tables are recently analyzed and there are a couple hundred 
> thousand rows in there. But I think I just figured it out.... it's a 
> 3-column index, and two columns of that index are the same for every row. 
> When I drop those two columns from the ordering restriction, the index 
> gets used and things speed up 5 orders of magnitude.
> Maybe the planner is smart enough to think that if a column in the order 
> by clause is identical for most rows, then using an index won't help.... 
> but not smart enough to realize that if said column is at the *end* of the 
> order by arguments, after columns which do sort quite well, then it should 
> use an index after all.
You're being about as clear as mud here, except that you obviously lied
about what you were doing in your first message.  If you have a planner
problem, show us the *exact* query, the *exact* table definition, and
unfaked EXPLAIN ANALYZE output.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2007-10-04 19:03:07 | Re: Tuning Help - What did I do wrong? | 
| Previous Message | Ben | 2007-10-04 18:33:39 | Re: quickly getting the top N rows |