From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Reduce heap tuple header size |
Date: | 2002-06-25 20:42:08 |
Message-ID: | 3D18D5A0.3680EEEA@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > Well, it turned out that pgbench does a terrible job with runtimes below
> > 30 minutes. Seems that one checkpoint more or less can have a
> > significant impact on the numbers reported by such run.
>
> Yeah, it is *very* painful to get reproducible numbers out of pgbench.
And since it seems to be extremly checkpoint dependent, imagine what
someone would have to do to measure the impact of changing config
options about checkpoint segments and intervals. But I guess that this
would be an issue for every benchmark.
The TPC must know about it as the specs for the TPC-C require at least
one checkpoint occuring during the measurement time and 90% of all
transactions fitting the timing constraints. Currently PostgreSQL
creates an IO storm on a checkpoint, that simply brings the system down
to responsetimes 100x the average, slowly recovering from there since
all simulated users are active at once then (they all woke up from their
thinking or keying times and pressed SEND).
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2002-06-25 20:54:17 | Re: Postgres idea list |
Previous Message | Tom Lane | 2002-06-25 20:20:36 | Re: Reduce heap tuple header size |
From | Date | Subject | |
---|---|---|---|
Next Message | David M. Kaplan | 2002-06-25 21:53:38 | ident-des patches |
Previous Message | Tom Lane | 2002-06-25 20:34:02 | Re: Dependency / Constraint patch |