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: | Raw Message | Whole Thread | 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 |