On Wed, 12 Feb 2003, [ISO-8859-1] Hans-J$B|(Brgen Sch$Bv(Bnig wrote:
(B
(B Be careful with sort_mem - this might lead to VERY unexpected results. I
(B did some testing on my good old Athlon 500 with a brand new IBM 120 Gigs
(B HDD. Reducing the sort_mem gave me significantly faster results
(B
(BActually, the results are completely expected once you know what's
(Bexactly is going on. I found it weird that my sorts were also slowing
(Bdown with more sort memory until Tom or Bruce or someone pointed out to
(Bme that my stats said my sorts were swapping.
(B
(B
(B
(Bthis way
Christopher Kings-Lynne wrote:
I reckon that sort_mem is the hardest thing to optimise1
Agreed... in part because it depends a lot on the query.
Also, if I understand correctly sort_mem not only affects sorts
but also hash table stuff as well, right? If that's true for
the new hash
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 8:54 PM
To: Hackers; Advocacy
Subject: [HACKERS] PostgreSQL Tuning Results
Hi Everyone,
I have just completed a basic set of benchmarking on our new
database server.
Hi Chris,
On Wed, 12 Feb 2003, Christopher Kings-Lynne wrote:
Machine:
256MB RAM, FreeBSD 4.7, EIDE HDD, 1 Ghz
Seems like a small amount of memory to be memory based tests with.
What about testing sort_mem as well. It would system to me that there
would be no negative to having infinite
Machine:
256MB RAM, FreeBSD 4.7, EIDE HDD, 1 Ghz
Seems like a small amount of memory to be memory based tests with.
Perhaps, but I'm benchmarking for that machine, not for any other. The
results have to include the 256MB spec.
Also, the peak was 25MB of SHM, which still leave 231MB for
Gavin Sherry wrote:
Hi Chris,
On Wed, 12 Feb 2003, Christopher Kings-Lynne wrote:
Machine:
256MB RAM, FreeBSD 4.7, EIDE HDD, 1 Ghz
Seems like a small amount of memory to be memory based tests with.
What about testing sort_mem as well. It would system to me that there
would be no
