Whilst doing some profiling of the server I found it useful to add an
option to pgbench to introduce a delay between client connection setup
and the start of the benchmark itself to allow me time to attach the
profiler to one of the backends.

Attached is the patch in case anyone finds a use for it, or if it's
deemed to be generally useful enough for inclusion in 8.4.

Regards, Dave.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Dave Page wrote:
> Whilst doing some profiling of the server I found it useful to add an
> option to pgbench to introduce a delay between client connection setup
> and the start of the benchmark itself to allow me time to attach the
> profiler to one of the backends.

Hmm, the backend already has a delay, see -W.

--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"Executive Executive Summary: The [Windows] Vista Content Protection
specification could very well constitute the longest suicide note in history."
Peter Guttman, http://www.cs.auckland.ac.nz/~pgut00...vista_cost.txt

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Mon, 2007-12-10 at 19:27 +0000, Dave Page wrote:
> Whilst doing some profiling of the server I found it useful to add an
> option to pgbench to introduce a delay between client connection setup
> and the start of the benchmark itself to allow me time to attach the
> profiler to one of the backends.

"postgres -W n" already does this. It is more flexible to put this
functionality in the backend that in individual client apps anyway.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Neil Conway wrote:
> On Mon, 2007-12-10 at 19:27 +0000, Dave Page wrote:
>> Whilst doing some profiling of the server I found it useful to add an
>> option to pgbench to introduce a delay between client connection setup
>> and the start of the benchmark itself to allow me time to attach the
>> profiler to one of the backends.
>
> "postgres -W n" already does this. It is more flexible to put this
> functionality in the backend that in individual client apps anyway.

I'm aware of postgres -W, but wanted something that wouldn't get in the
way of other connections and would only affect my pgbench tests.

If the patch is of no interest, please just ignore it. I just posted it
for anyone that may find it useful - I'm not pushing to have it committed.

Regards, Dave.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Dave Page wrote:

> I'm aware of postgres -W, but wanted something that wouldn't get in the
> way of other connections and would only affect my pgbench tests.

I think you could get the same effect by putting the -W in PGOPTIONS (in
pgbench's environment).

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"No renuncies a nada. No te aferres a nada."

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Alvaro Herrera wrote:
> Dave Page wrote:
>
>> I'm aware of postgres -W, but wanted something that wouldn't get in the
>> way of other connections and would only affect my pgbench tests.
>
> 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.

/D

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Dave Page <dpage@postgresql.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.
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...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, 10 Dec 2007, Tom Lane wrote:

> I concur with Alvaro that this case seems adequately covered by
> PGOPTIONS="-W n" pgbench ...

I started to disagree with this, but ultimately realized anyone who is
running pgbench for long enough to get useful results shouldn't have their
TPS impacted much at all by a few overhead seconds tacked onto the server
startup.

I once wrote a similar patch to the one Dave submitted here and feel like
it's worth committing at least a documentation patch to show how to deal
with this. It's not obvious that pgbench pays attention to the
environment variables at all, and it's even less obvious that you can pass
what look like server options in there. I just poked around the
documentation a bit and I didn't find anything that cleared up which
options you can pass from a client; in addition to -W, I can imagine
pgbench users might also want to use -S (sort memory) or -f (forbid
scan/join types). If I can get someone to clarify what is supported there
I can put together a pgbench doc patch that addresses this topic.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Mon, 2007-12-10 at 19:12 -0500, Greg Smith wrote:
> I just poked around the
> documentation a bit and I didn't find anything that cleared up which
> options you can pass from a client

http://www.postgresql.org/docs/8.2/s...pq-envars.html

Which says only "PGOPTIONS sets additional run-time options for the
PostgreSQL server." This could probably be elaborated upon -- for the
list of options accepted, see PostgresMain() in tcop/postgres.c

Perhaps one of the slightly unfortunate consequences of the postmaster
=> postgres merge is that there is less of a clear distinction between
"postmaster options" and "postgres" options...

-Neil



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Greg Smith <gsmith@gregsmith.com> writes:
> I once wrote a similar patch to the one Dave submitted here and feel like
> it's worth committing at least a documentation patch to show how to deal
> with this. It's not obvious that pgbench pays attention to the
> environment variables at all, and it's even less obvious that you can pass
> what look like server options in there.

It's not pgbench that is paying attention to this, it's libpq.
This is at least referred to in the libpq and server documentation,
eg the tenth paragraph here:
http://developer.postgresql.org/pgdo...g-setting.html
It might be worth more emphasis, not sure. It doesn't come up all
that often.

> I just poked around the
> documentation a bit and I didn't find anything that cleared up which
> options you can pass from a client; in addition to -W, I can imagine
> pgbench users might also want to use -S (sort memory) or -f (forbid
> scan/join types). If I can get someone to clarify what is supported there
> I can put together a pgbench doc patch that addresses this topic.

Anything you'd be allowed to SET can be set from PGOPTIONS (-c or --var
syntax). As for the special-purpose postgres command-line switches,
I believe they are all equivalent to one or another GUC variable:
http://developer.postgresql.org/pgdo...fig-short.html
so the restrictions are the same as for the underlying variable.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly