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

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

From: Devin Ben-Hur <dbenhur(at)whitepages(dot)com>
To: Marc Cousin <cousinmarc(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Very big insert/join performance problem (bacula)
Date: 2009-07-16 22:29:48
Message-ID: 4A5FA9DC.3020905@whitepages.com (view raw or flat)
Thread:
Lists: pgsql-performance
Marc Cousin wrote:
> 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...
> 
> 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 ?

cached_buffer_cost = 0.01
effective_page_cost =
   ((1 - expected_cache_hit_ratio) * standard_page_cost)
+ (expected_cache_hit_ratio       * cached_buffer_cost)

If your assumption is only about these queries in particular, rather 
than applicable across the board, you should set the page_costs just for 
this query and reset them or close the connection after.

-- 
-Devin

In response to

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2009-07-16 22:30:17
Subject: Re: Very big insert/join performance problem (bacula)
Previous:From: Marc CousinDate: 2009-07-16 22:03:24
Subject: Re: Very big insert/join performance problem (bacula)

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