| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chris Shoemaker <chris(dot)shoemaker(at)cox(dot)net> |
| Cc: | Shane Ambler <pgsql(at)Sheeky(dot)Biz>, pgsql-performance(at)postgresql(dot)org, ejones(at)engineyard(dot)com |
| Subject: | Re: Adding "LIMIT 1" kills performance. |
| Date: | 2008-05-29 17:59:11 |
| Message-ID: | 1866.1212083951@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Chris Shoemaker <chris(dot)shoemaker(at)cox(dot)net> writes:
> Still stumped,
The short answer here is that the planner is guessing that scanning the
index in ID order will come across the desired row (ie, the first one
matching the join condition) in less time than it will take to select
all the joinable rows, sort them by ID, and take the first one. It's
wrong in this case, but the plan is not unreasonable on its face.
The problem boils down to a misestimate of how many join rows there are.
You might get better results by increasing the statistics targets.
There are plenty of similar cases in the list archives.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2008-05-29 19:50:48 | Re: 2GB or not 2GB |
| Previous Message | Chris Shoemaker | 2008-05-29 17:47:12 | Re: Adding "LIMIT 1" kills performance. |