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

Re: Fork-based version of pgbench

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fork-based version of pgbench
Date: 2005-12-02 06:40:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> It's not so much that I want to inflate the measurements, as that
> leaving 10% of the CPU on the table reduces pgbench's usefulness as
> a way of stress-testing the backend.

I suspect the difference is the same thing you theorised made the difference
before. Namely that they're no longer proceeding in lockstep. The progress is
more random allowing some processes to make more progress than average and
benefit from better, er, well some cache somewhere.

In any case it seems like there would be cases where each kind of behaviour
would be useful. It seems likely there would be bugs where the lockstep
behaviour was useful for testing, and other bugs where the randomized
behaviour would be useful for testing too.


In response to


pgsql-hackers by date

Next:From: Greg StarkDate: 2005-12-02 06:44:08
Subject: Re: Reducing relation locking overhead
Previous:From: Joshua D. DrakeDate: 2005-12-02 05:19:10
Subject: Additional Grant/revoke problem

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