From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgbench--new transaction type |
Date: | 2011-06-20 04:34:18 |
Message-ID: | BANLkTinfnZnyjxv73VKAwQNT3YXFmpby2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 20, 2011 at 07:30, Greg Smith <greg(at)2ndquadrant(dot)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 only one 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-06-20 04:53:25 | Re: Latch implementation that wakes on postmaster death on both win32 and Unix |
Previous Message | Greg Smith | 2011-06-20 04:25:08 | Re: Patch - Debug builds without optimization |