On Apr 14, 2008, at 3:31 PM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
The transition domain where performance drops dramatically as the
database
starts to not fit in shared buffers but does still fit in
filesystem cache.
It looks to me like the knee comes where the DB no lo
Gaetano Mendola wrote:
> Hi all,
> I started to do some performance tests (using pgbench) in order to
> estimate the DRBD impact on our servers, my plan was to perform some
> benchmarks without DRBD in order to compare the same benchmark with
> DRBD.
> I didn't perform yet the benchmark with DRBD a
Greg Smith wrote:
> On Mon, 14 Apr 2008, Gaetano Mendola wrote:
>
>> I'm using postgres 8.2.3 on Red Hat compiled with GCC 3.4.6.
>
> 8.2.3 has a performance bug that impacts how accurate pgbench results
> are; you really should be using a later version.
>
>> http://img84.imageshack.us/my.php?im
Greg Smith wrote:
> On Mon, 14 Apr 2008, Gaetano Mendola wrote:
>
>> I'm using postgres 8.2.3 on Red Hat compiled with GCC 3.4.6.
>
> 8.2.3 has a performance bug that impacts how accurate pgbench results
> are; you really should be using a later version.
Thank you, I will give it a shot and perf
On Mon, 14 Apr 2008, Tom Lane wrote:
Ideally, very hot pages would stay in shared buffers and drop out of the
kernel cache, allowing you to use a database approximating all-of-RAM
before you hit the performance wall.
With "pgbench -S", the main hot pages that get elevated usage counts and
cli
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The transition domain where performance drops dramatically as the database
>> starts to not fit in shared buffers but does still fit in filesystem cache.
>
> It looks to me like the knee comes where the DB no lon
Gregory Stark <[EMAIL PROTECTED]> writes:
> The transition domain where performance drops dramatically as the database
> starts to not fit in shared buffers but does still fit in filesystem cache.
It looks to me like the knee comes where the DB no longer fits in
filesystem cache. What's interesti
On Mon, 14 Apr 2008, Gregory Stark wrote:
I'm curious about the total database size as a for each of the scaling factors
as well as the total of the index sizes.
That's all in a table at
http://www.westnet.com/~gsmith/content/postgresql/pgbench-scaling.htm
--
* Greg Smith [EMAIL PROTECTED]
On Mon, 14 Apr 2008, Gaetano Mendola wrote:
I'm using postgres 8.2.3 on Red Hat compiled with GCC 3.4.6.
8.2.3 has a performance bug that impacts how accurate pgbench results are;
you really should be using a later version.
http://img84.imageshack.us/my.php?image=totalid7.png
as you can se
Gregory Stark wrote:
"Gaetano Mendola" <[EMAIL PROTECTED]> writes:
The following graph reports the results:
http://img84.imageshack.us/my.php?image=totalid7.png
That's a *fascinating* graph.
It is, isn't it? Thanks Gaetano.
It seems there are basically three domains.
The small domain w
"Gaetano Mendola" <[EMAIL PROTECTED]> writes:
> The following graph reports the results:
>
> http://img84.imageshack.us/my.php?image=totalid7.png
That's a *fascinating* graph.
It seems there are basically three domains.
The small domain where the database fits in shared buffers -- though actua
Hi all,
I started to do some performance tests (using pgbench) in order to
estimate the DRBD impact on our servers, my plan was to perform some
benchmarks without DRBD in order to compare the same benchmark with
DRBD.
I didn't perform yet the benchmark with DRBD and I'm already facing
something I c
12 matches
Mail list logo
