Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] 8.3beta1 testing on Solaris

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)sun(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris
Date: 2007-10-26 08:07:23
Message-ID: 87wsta70zo.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
"Josh Berkus" <josh(at)agliodbs(dot)com> writes:

> Actually, 32 made a significant difference as I recall ... do you still have 
> the figures for that, Jignesh?

Well it made a difference but it didn't remove the bottleneck, it just moved
it. IIRC under that benchmark Jignesh was able to run with x sessions
efficiently with 8 clog buffers, x + 100 or so sessions with 16 clog buffers
and x + 200 or so sessions with 32 clog buffers.

It happened that x + 200 was > the number of sessions he wanted to run the
benchmark at so it helped the benchmark results quite a bit. But that was just
an artifact of how many sessions the benchmark needed. A user who needs 1200
sessions or who has a different transaction load might find he needs more clog
buffers to alleviate the bottleneck. And of course most (all?) normal users
use far fewer sessions and won't run into this bottleneck at all.

Raising NUM_CLOG_BUFFERS just moves around the arbitrary bottleneck. This
benchmark is useful in that it gives us an idea where the bottleneck lies for
various values of NUM_CLOG_BUFFERS but it doesn't tell us what value realistic
users are likely to bump into.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

pgsql-performance by date

Next:From: Giulio Cesare SolaroliDate: 2007-10-26 12:41:36
Subject: Re: Finalizing commit taking very long
Previous:From: Tom LaneDate: 2007-10-26 03:26:08
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris

pgsql-hackers by date

Next:From: Adrian MaierDate: 2007-10-26 08:15:47
Subject: Re: module archive
Previous:From: Magnus HaganderDate: 2007-10-26 07:56:03
Subject: Re: 8.3 GSS Issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group