Re: pgbench transaction timestamps

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Cc: bruce(at)momjian(dot)us, gsmith(at)gregsmith(dot)com, pgsql-patches(at)postgresql(dot)org
Subject: Re: pgbench transaction timestamps
Date: 2007-04-06 02:21:56
Message-ID: 20070406.112156.21302689.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> > Tatsuo, would you please comment on this patch too?
>
> No problem. I will come up with a comment by the end of this week.

Here are comments.

1) latency log file format extention looks usefull (-x option).

2) it seems the "cleanup feature" (-X option) was withdrawed by the
author, but the patches still include the feature. So I'm confused.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> > ---------------------------------------------------------------------------
> >
> > Greg Smith wrote:
> > > This patch changes the way pgbench outputs its latency log files so that
> > > every transaction gets a timestamp and notes which transaction type was
> > > executed. It's a one-line change that just dumps some additional
> > > information that was already sitting in that area of code. I also made a
> > > couple of documentation corrections and clarifications on some of the more
> > > confusing features of pgbench.
> > >
> > > It's straightforward to parse log files in this format to analyze what
> > > happened during the test at a higher level than was possible with the
> > > original format. You can find some rough sample code to convert this
> > > latency format into CVS files and then into graphs at
> > > http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm which I'll
> > > be expanding on once I get all my little patches sent in here.
> > >
> > > If you recall the earlier version of this patch I submitted, it added a
> > > cleanup feature that did a vacuum and checkpoint after the test was
> > > finished and reported two TPS results. The idea was to quantify how much
> > > of a hit the eventual table maintenance required to clean up after the
> > > test would take. While those things do influence results and cause some
> > > of the run-to-run variation in TPS (checkpoints are particularly visible
> > > in the graphs), after further testing I concluded running a VACUUM VERBOSE
> > > and CHECKPOINT in a script afterwards and analyzing the results was more
> > > useful than integrating something into pgbench itself.
> > >
> > > --
> > > * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
> > Content-Description:
> >
> > [ Attachment, skipping... ]
> >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: explain analyze is your friend
> >
> > --
> > Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> > EnterpriseDB http://www.enterprisedb.com
> >
> > + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2007-04-06 02:35:30 Re: Optimized pgbench for 8.3
Previous Message Chris Browne 2007-04-06 02:02:56 Re: What X86/X64 OS's do we need coverage for?

Browse pgsql-patches by date

  From Date Subject
Next Message Tatsuo Ishii 2007-04-06 02:35:30 Re: Optimized pgbench for 8.3
Previous Message Simon Riggs 2007-04-05 21:56:41 Reviewers Guide to Deferred Transactions/Transaction Guarantee