| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | josh(at)agliodbs(dot)com, Markus Schaber <schabios(at)logi-track(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL Performance List <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Automagic tuning |
| Date: | 2005-02-01 05:06:27 |
| Message-ID: | 10114.1107234387@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> On Mon, Jan 31, 2005 at 03:26:12PM -0500, Tom Lane wrote:
>> Preferably a whole lot of queries. All the measurement techniques I can
>> think of are going to have a great deal of noise, so you shouldn't
>> twiddle these cost settings based on just a few examples.
> Are there any examples of how you can take numbers from pg_stats_* or
> explain analize and turn them into configuration settings (such and
> random page cost)?
Well, the basic idea is to adjust random_page_cost so that the ratio of
estimated cost to real elapsed time (as shown by EXPLAIN ANALYZE) is the
same for seqscans and indexscans. What you have to watch out for is
that the estimated cost model is oversimplified and doesn't take into
account a lot of real-world factors, such as the activity of other
concurrent processes. The reason for needing a whole lot of tests is
essentially to try to average out the effects of those unmodeled
factors, so that you have a number that makes sense within the planner's
limited view of reality.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-02-01 05:29:15 | Re: Index Slowing Insert >50x |
| Previous Message | Jim C. Nasby | 2005-02-01 04:56:45 | Re: High end server and storage for a PostgreSQL OLTP system |