| From: | Timothy Garnett <tgarnett(at)panjiva(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | sthomas(at)peak6(dot)com, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 |
| Date: | 2011-03-17 20:33:03 |
| Message-ID: | AANLkTin8hQF89SKGJ3JM=USSiK9PE=tEoPoS_CKMMcTo@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Thanks, we'll give these a try.
Tim
On Thu, Mar 17, 2011 at 2:13 PM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:
> Timothy Garnett <tgarnett(at)panjiva(dot)com> wrote:
>
> > We'd still be interested in other suggestions for convincing the
> > query planner not to pick the bad plan in this case
>
> You could try boosting cpu_tuple_cost. I've seen some evidence that
> the default number is a bit low in general, so it wouldn't
> necessarily be bad to try your whole load with a higher setting. If
> that doesn't work you could set it for the one query. If that
> setting alone doesn't do it, you could either decrease both page
> cost numbers or multiply all the cpu numbers (again, probably
> boosting cpu_tuple_cost relative to the others).
>
> -Kevin
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Charles | 2011-03-18 00:51:52 | Request for feedback on hardware for a new database server |
| Previous Message | Kevin Grittner | 2011-03-17 18:13:53 | Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 |