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

Re: pgbench - startup delay

From: Dave Page <dpage(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pgbench - startup delay
Date: 2007-12-11 09:09:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>> Alvaro Herrera wrote:
>>> I think you could get the same effect by putting the -W in PGOPTIONS (in
>>> pgbench's environment).
>> That's a good point. It does have the downside that it will affect the
>> pgbench results - though that wouldn't actually be an issue for what I
>> was doing.
> Well, if you're attaching a profiler or debugger to a backend, you're
> hardly gonna get unadulterated TPS readings from pgbench anyway. 

No, but it can be a simple consistency check between multiple profiler
runs - but then it doesn't matter if it's affected by delay of course as
long as it's of a consistent length.

One small advantage of doing this client-side (which I'm pretty sure
noone can shoot down :-) ) is that the initial connection used to vacuum
etc. isn't delayed which could be annoying.

> I concur with Alvaro that this case seems adequately covered by
> 	PGOPTIONS="-W n" pgbench ...
> which is what I've always used in similar situations...

Fair 'enuff :-)


In response to

pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-12-11 09:09:20
Subject: Re: Proposed patch to disallow password=foo in database name parameter
Previous:From: Magnus HaganderDate: 2007-12-11 09:00:22
Subject: Re:

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