> So 7.0.3 is twice as fast only with fsync off.
Are there FK updates/deletes in pgbench' tests?
Remember how SELECT FOR UPDATE in FK triggers
affects performance...
Also, 5 clients is small number.
Vadim
P.S. Sorry for delays with my replies -
internet connection is pain here: it takes
5-10 min
Oops I screwed up again. :)
I was actually right the first time my postgresql 7.0.3 was running with
fsync off. Due to my weird results I searched more thoroughly and found my
7.0.3's pg_options had a nofsync=1.
So 7.0.3 is twice as fast only with fsync off.
7.1beta4 snapshot - fsync.
./pgben
On Fri, 23 Feb 2001, Hannu Krosing wrote:
HK> > DM> I just done the experiment with increasing HZ to 1000 on my own machine
HK> > DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
HK> > DM> of increasing HZ is surely more overhead to scheduler system. Anyway, it's
HK> >
> It may be that WAL has changed the rollback
> time-characteristics to worse than pre-wal ?
Nothing changed ... yet. And in future rollbacks
of read-only transactions will be as fast as now,
anyway.
> > So my guess is that the 7.1 updates (with default
> > fsync) are significantly slower than 7
> > > It may be that WAL has changed the rollback
> > > time-characteristics to worse than pre-wal ?
> >
> > Nothing changed ... yet. And in future rollbacks
> > of read-only transactions will be as fast as now,
> > anyway.
>
> What about rollbacks of a bunch uf inserts/updates/deletes?
>
> I rem
> Okay, plan B then: let's ask people to redo their benchmarks with
> -s bigger than one. Now, how much bigger?
>
> To the extent that you think this is a model of a real bank, it should
> be obvious that the number of concurrent transactions cannot exceed the
> number of tellers; there should n
At 09:40 AM 22-02-2001 -0500, Vadim Mikheev wrote:
>> It may be that WAL has changed the rollback
>> time-characteristics to worse than pre-wal ?
>
>Nothing changed ... yet. And in future rollbacks
>of read-only transactions will be as fast as now,
>anyway.
The rollbacks are ok for me at least -
> -Original Message-
> From: Tom Lane
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
> > connecting each client to its own database, so that locking and such
> > does not shade the possible benefits (was it about 15% ?)
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> It seems to me that the branches table should have at least 10 to 100
>> entries, and tellers about 10 times whatever branches is. 10
>> accounts rows seems enough though.
> Those numbers are defined in the TPC-B spec.
Ah. And of course, the TPC
> I didn't much like that approach to altering the test, since it also
> means that all the clients are working with separate tables and hence
> not able to share read I/O; that doesn't seem like it's the same
> benchmark at all. What would make more sense to me is to increase the
> number of row
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
> connecting each client to its own database, so that locking and such
> does not shade the possible benefits (was it about 15% ?) of delay>1
I didn't much like that approach to alterin
Vadim Mikheev wrote:
>> Should this kind of usage be replaced in the future by
>> having backend id as a key and then doing delete by that
>> key in the end ?
>
>
> Isn't it what we have right now?
I meant doing it at the application level, not what backend does internally.
Like we are supp
On Fri, Feb 23, 2001 at 01:09:37PM +0200, Hannu Krosing wrote:
> Dmitry Morozovsky wrote:
>
> > DM> I just done the experiment with increasing HZ to 1000 on my own machine
> > DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
> > DM> of increasing HZ is surely more overh
Lincoln Yeoh wrote:
>
> Oops.
>
> I rechecked the start up script, and the 7.0.3 doesn't have fsync off or
> whatever. Dunno why I thought it was on (heh maybe because it was a lot
> faster than 6.5.3!).
>
> Hmm, this means 7.0.3 is quite fast...
>
Your app seems to have many rollbacks.
Yes ro
Vadim Mikheev wrote:
>
> > It may be that WAL has changed the rollback
> > time-characteristics to worse than pre-wal ?
>
> Nothing changed ... yet. And in future rollbacks
> of read-only transactions will be as fast as now,
> anyway.
What about rollbacks of a bunch uf inserts/updates/deletes?
Lincoln Yeoh wrote:
>
> Just another data point.
>
> I downloaded a snapshot yesterday - Changelogs dated Feb 20 17:02
>
> It's significantly slower than "7.0.3 with fsync off" for one of my webapps.
>
> 7.0.3 with fsync off gets me about 55 hits per sec max (however it's
> interesting that th
I wrote:
>
> I tried with -B 1024 10 times for commit_delay=0 and 1 respectively.
> The average result of 'pgbench -c 10 -t 100' is as follows.
>
> [commit_delay=0]
> 26.462817(including connections establishing)
> 26.788047(excluding connections establishing)
> [commit_delay=1]
> 27.630405(in
Just another data point.
I downloaded a snapshot yesterday - Changelogs dated Feb 20 17:02
It's significantly slower than "7.0.3 with fsync off" for one of my webapps.
7.0.3 with fsync off gets me about 55 hits per sec max (however it's
interesting that the speed keeps dropping with continued t
Oops.
I rechecked the start up script, and the 7.0.3 doesn't have fsync off or
whatever. Dunno why I thought it was on (heh maybe because it was a lot
faster than 6.5.3!).
Hmm, this means 7.0.3 is quite fast...
Cheerio,
Link.
> Tom Lane wrote:
> >
> > > platform) i686-pc-linux-gnu, compiled by GCC
> egcs-2.91.60(turbolinux 4.2)
> > > min delay) 10msec according to your test program.
> > > -B) 64 (all other settings are default)
> >
> > Thanks. Could I trouble you to run it again with a larger -B, say
> > 1024 or 20
I Inoue wrote:
>
> Tom Lane wrote:
> >
> > > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > > min delay) 10msec according to your test program.
> > > -B) 64 (all other settings are default)
> >
> > Thanks. Could I trouble you to run it again with a larger -B, say
>
Tom Lane wrote:
>
> > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > min delay) 10msec according to your test program.
> > -B) 64 (all other settings are default)
>
> Thanks. Could I trouble you to run it again with a larger -B, say
> 1024 or 2048? What I've foun
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> Hmm, you mean you set up a separate test database for each pgbench
> >> "client", but all under the same postmaster?
>
> > Yes. Different database is to make the conflict as less as possible.
> > The conflict among backends is a
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> Hmm, you mean you set up a separate test database for each pgbench
>> "client", but all under the same postmaster?
> Yes. Different database is to make the conflict as less as possible.
> The conflict among backends is a greatest enemy of CommitDelay
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I changed pgbench so that different connection connects
> > to the different database and got the following results.
>
> Hmm, you mean you set up a separate test database for
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I changed pgbench so that different connection connects
> to the different database and got the following results.
Hmm, you mean you set up a separate test database for each pgbench
"client", but all under the same postmaster?
> The results of
> p
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I've been suspicious if pgbench is an (unique)
> > appropiriate test case for evaluaing commit_delay.
>
> Of course it isn't. Never trust only one benchmark.
>
> I've asked the Great Bridge folks to run their TPC-C benchmark with
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I've been suspicious if pgbench is an (unique)
> appropiriate test case for evaluaing commit_delay.
Of course it isn't. Never trust only one benchmark.
I've asked the Great Bridge folks to run their TPC-C benchmark with both
zero and small nonzero com
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > In your test cases I always see "where bid = 1" at "update branches"
> > i.e.
> > update branches set bbalance = bbalance + ... where bid = 1
>
> > ISTM there's no multiple COMMIT in your senario-s due to
> > their lock conflicts
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> In your test cases I always see "where bid = 1" at "update branches"
> i.e.
> update branches set bbalance = bbalance + ... where bid = 1
> ISTM there's no multiple COMMIT in your senario-s due to
> their lock conflicts.
Hmm. It looks like using a
I did not realize how much WAL improved performance when using fsync.
> > "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > > So, is it OK to use commit_delay=0?
> >
> > Certainly. In fact, I think that's about to become the default ;-)
>
> I agree with Tom. I did some benchmarking tests using
Tom Lane wrote:
>
> I wrote:
> > Thus, our past arguments about whether a few microseconds of delay
> > before commit are a good idea seem moot; we do not have any portable way
> > of implementing that, and a ten millisecond delay for commit is clearly
> > Not Good.
>
> I've now finished running
On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:
DM> I just done the experiment with increasing HZ to 1000 on my own machine
DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
DM> of increasing HZ is surely more overhead to scheduler system. Anyway, it's
DM> a bit of data to
On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:
I just done the experiment with increasing HZ to 1000 on my own machine
(PII 374). Your test program reports 2 ms instead of 20. The other side
of increasing HZ is surely more overhead to scheduler system. Anyway, it's
a bit of data to dig into, I sup
> TL> I vote for commit_delay = 0, unless someone can show cases where
> TL> positive delay is significantly better than zero delay.
>
> BTW, for modern versions of FreeBSD kernels, there is HZ kernel option
> which describes maximum timeslice granularity (actually, HZ value is
> number of timesl
On Sat, 17 Feb 2001, Tom Lane wrote:
[skip]
TL> Platform: HPUX 10.20 on HPPA C180, fast wide SCSI discs, 7200rpm (I think).
TL> Minimum select(2) delay is 10 msec on this platform.
[skip]
TL> I vote for commit_delay = 0, unless someone can show cases where
TL> positive delay is significantly b
* Tom Lane <[EMAIL PROTECTED]> [010216 22:49]:
> "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > So, is it OK to use commit_delay=0?
>
> Certainly. In fact, I think that's about to become the default ;-)
>
> I have now experimented with several different platforms --- HPUX,
> FreeBSD, and two
lockhart> > ... See included png file.
lockhart>
lockhart> What kind of machine was this run on?
lockhart>
lockhart> - Thomas
Sorry to forget to mention about that.
SONY VAIO Z505CR/K (note PC)
Pentium III 750MHz/256MB memory/20GB IDE HDD
Linux (kernel 2.2.17)
configure --
> ... See included png file.
What kind of machine was this run on?
- Thomas
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I agree with Tom. I did some benchmarking tests using pgbench for a
> computer magazine in Japan. I got a almost equal or better result for
> 7.1 than 7.0.3 if commit_delay=0. See included png file.
Interesting curves. One thing you might like to know i
> "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > So, is it OK to use commit_delay=0?
>
> Certainly. In fact, I think that's about to become the default ;-)
I agree with Tom. I did some benchmarking tests using pgbench for a
computer magazine in Japan. I got a almost equal or better result for
I wrote:
> Thus, our past arguments about whether a few microseconds of delay
> before commit are a good idea seem moot; we do not have any portable way
> of implementing that, and a ten millisecond delay for commit is clearly
> Not Good.
I've now finished running a spectrum of pgbench scenarios,
"Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> So, is it OK to use commit_delay=0?
Certainly. In fact, I think that's about to become the default ;-)
I have now experimented with several different platforms --- HPUX,
FreeBSD, and two considerably different strains of Linux --- and I find
that t
43 matches
Mail list logo
