Skip site navigation (1) Skip section navigation (2)

Re: Very big insert/join performance problem (bacula)

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 (view raw or flat)
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 ?


In response to

Responses

pgsql-performance by date

Next:From: Greg StarkDate: 2009-07-16 21:01:42
Subject: Re: cluster index on a table
Previous:From: Greg StarkDate: 2009-07-16 20:49:26
Subject: Re: cluster index on a table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group