Re: New to PostgreSQL, performance considerations

From: "Gregory S(dot) Williamson" <gsw(at)globexplorer(dot)com>
To: "Michael Glaesemann" <grzm(at)seespotcode(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Alexander Staubo" <alex(at)purefiction(dot)net>, "Michael Stone" <mstone+postgres(at)mathom(dot)us>
Subject: Re: New to PostgreSQL, performance considerations
Date: 2006-12-14 06:49:05
Message-ID: 71E37EF6B7DCC1499CEA0316A256832802B3EA13@loki.wc.globexplorer.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

(Re)-Design it to do both, unless there's reason to believe that doing one after the other would skew the results.

Then old results are available, new results are also visible and useful for future comparisons. And seeing them side by side mught be an interesting exercise as well, at least for a while.

(sorry for top-posting -- web based interface that doesn't do proper quoting)

Greg Williamson
DBA
GlobeXplorer LLC

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org on behalf of Michael Glaesemann
Sent: Wed 12/13/2006 10:11 PM
To: Tom Lane
Cc: Joshua D. Drake; Josh Berkus; pgsql-performance(at)postgresql(dot)org; Bruce Momjian; Alvaro Herrera; Alexander Staubo; Michael Stone
Subject: Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 14, 2006, at 14:44 , Tom Lane wrote:

> The pgbench app itself becomes the bottleneck at high transaction
> rates. Awhile back I rewrote it to improve its ability to issue
> commands concurrently, but then desisted from submitting the
> changes --- if we change the app like that, future numbers would
> be incomparable to past ones, which sort of defeats the purpose of a
> benchmark no?

At the same time, if the current pgbench isn't the tool we want to
use, is this kind of backward comparison going to hinder any move to
improve it? It sounds like there's quite a bit of room for
improvement in pg_bench, and in my opinion we should move forward to
make an improved tool, one that measures what we want to measure. And
while comparison with past results might not be possible, there
remains the possibility of rerunning the improved pgbench on previous
systems, I should think.

Michael Glaesemann
grzm seespotcode net

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

-------------------------------------------------------
Click link below if it is SPAM gsw(at)globexplorer(dot)com
"https://mailscanner.globexplorer.com/dspam/dspam.cgi?signatureID=4580ea76236074356172766&user=gsw(at)globexplorer(dot)com&retrain=spam&template=history&history_page=1"
!DSPAM:4580ea76236074356172766!
-------------------------------------------------------

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Evgeny Gridasov 2006-12-14 13:32:30 EXPLAIN ANALYZE on 8.2
Previous Message Ron 2006-12-14 06:45:29 Re: New to PostgreSQL, performance considerations