Date: Mon, 21 Jul 2003 14:15:44 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Tom Samplonius <tom@sdf.com> Cc: freebsd-performance@freebsd.org Subject: Re: Tuning for PostGreSQL Database Message-ID: <20030721141544.4ef4a0d6.Alexander@Leidinger.net> In-Reply-To: <Pine.BSF.4.05.10307201447370.16986-100000@misery.sdf.com> References: <20030720112550.GO24507@perrin.int.nxad.com> <Pine.BSF.4.05.10307201447370.16986-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Jul 2003 14:53:33 -0700 (PDT) Tom Samplonius <tom@sdf.com> wrote: > Well, 5.1 is considerably less crippled by Giant than 4.8. Well, > "crippled" is not a good description. "Impaired" is better. 5.1 SMP > performance is less Giant impaired than 4.8. That's a good thing. The critical parts for the desired operations are still covered by the Giant lock (e.g. tcp stack, ata subsystem). > > over takes 4.X in terms of speed, is the subject of great debate, but > > many are optimistic that it will be at some point, just not at the > > moment. 5.X, will however (and without much doubt), scale much better > > than 4.X on multiple processor machines, though I'm not sure where > > that stands at the moment in terms of being completed and should > > likely be directed to current@ or questions@ instead of here. -sc > > Yes, 5.1 is better on multiple CPUs. So if 5.1 works for you, it is > going to work faster than 4.8 on SMP. Did you measured that, and if yes, which set of operations do you have banchmarked? On -current we still have reports that 5.1 is still not as fast as 4.8 (and nobody @FreeBSD.org is surprised, as the target is to first get a stable 5.x line and after that a fast&stable one). Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030721141544.4ef4a0d6.Alexander>