| From: | Marc Cousin <cousinmarc(at)gmail(dot)com> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Very big insert/join performance problem (bacula) |
| Date: | 2009-07-16 20:50:10 |
| Message-ID: | 200907162250.11010.cousinmarc@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Le Thursday 16 July 2009 22:07:25, Kevin Grittner a écrit :
> Marc Cousin <cousinmarc(at)gmail(dot)com> wrote:
> > the hot parts of these 2 tables are extremely likely to be in the
> > database or linux cache (buffer hit rate was 97% in the example
> > provided). Moreover, the first two queries of the insert procedure
> > fill the cache for us...
>
> This would be why the optimizer does the best job estimating the
> relative costs of various plans when you set the random_page_cost and
> seq_page_cost very low.
>
> -Kevin
Ok, so to sum it up, should I keep these values (I hate doing this :) ) ?
Would there be a way to approximately evaluate them regarding to the expected
buffer hit ratio of the query ?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2009-07-16 21:01:42 | Re: cluster index on a table |
| Previous Message | Greg Stark | 2009-07-16 20:49:26 | Re: cluster index on a table |