From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgbench--new transaction type |
Date: | 2011-06-20 18:45:24 |
Message-ID: | 4DFF9544.3030204@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro wrote:
> 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.
>
When you execute using "-f", it doesn't correctly detect database
scale. Also, the really valuable thing here is seeing the higher
selects/second number come out in the report. I just realized neither
Jeff nor myself ever included an example of the output in the new mode,
which helps explain some of why the patch is built the way it is:
$ pgbench -c 12 -j 4 -T 30 -P pgbench
plgsql function created.
starting vacuum...end.
transaction type: SELECT only via plpgsql
scaling factor: 100
query mode: simple
number of clients: 12
number of threads: 4
duration: 30 s
number of transactions actually processed: 9342
tps = 311.056293 (including connections establishing)
tps = 311.117886 (excluding connections establishing)
selects per second = 159260.822100 (including connections establishing)
selects per second = 159292.357672 (excluding connections establishing)
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-06-20 18:46:44 | Re: [WIP] cache estimates, cache access cost |
Previous Message | Darren Duncan | 2011-06-20 18:38:58 | Re: Range Types and extensions |