Re: pgbench--new transaction type - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: pgbench--new transaction type
Date
Msg-id BANLkTinfnZnyjxv73VKAwQNT3YXFmpby2Q@mail.gmail.com
Whole thread Raw
In response to Re: pgbench--new transaction type  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: pgbench--new transaction type
Re: pgbench--new transaction type
List pgsql-hackers
On Mon, Jun 20, 2011 at 07:30, Greg Smith <greg@2ndquadrant.com> wrote:
> I applied Jeff's patch but changed this to address concerns about the
> program getting stuck running for too long in the function:
>
> #define plpgsql_loops   512

Is it OK to define the value as constant?

Also, it executes much more queries if -t option (transactions) specified;
Of course it runs the specified number of "transactions", but actually
runs plpgsql_loops times than other modes.

> I think this is a really nice new workload to demonstrate.  One of the
> things we tell people is that code works much faster when moved server-side,

What is the most important part of the changes? The proposal includes
3 improvements. It might defocus the most variable tuning point.
#1 Execute multiple queries in one transaction.#2 Run multiple queries in the server with stored procedure.#3 Return
onlyone value instead of 512. 

Anyway, I'm not sure we need to include the query mode into the pgbench's
codes. Instead, how about providing "a sample script" as a separate sql
file? pgbench can execute any script files with -f option.

--
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Patch - Debug builds without optimization
Next
From: Fujii Masao
Date:
Subject: Re: Latch implementation that wakes on postmaster death on both win32 and Unix