From: | "P(dot)J(dot) \"Josh\" Rovero" <rovero(at)sonalysts(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Paul Tillotson <pntil(at)shentel(dot)net>, David Esposito <pgsql-general(at)esposito(dot)newnetco(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Performance tuning on RedHat Enterprise Linux 3 |
Date: | 2004-12-07 12:50:44 |
Message-ID: | 41B5A724.7070907@sonalysts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
There are many reports of kernel problems with memory allocation
(too agressive) and swap issues with RHEL 3.0 on both RAID
and non-RAID systems. I hope folks have worked through all
those issues before blaming postgresql.
Tom Lane wrote:
>
> If I thought that a 200% error in memory usage were cause for a Chinese
> fire drill, then I'd say "yeah, let's do that". The problem is that the
> place where performance actually goes into the toilet is normally an
> order of magnitude or two above the nominal sort_mem setting (for
> obvious reasons: admins can't afford to push the envelope on sort_mem
> because of the various unpredictable multiples that may apply). So
> switching to a hugely more expensive implementation as soon as we exceed
> some arbitrary limit is likely to be a net loss not a win.
>
> If you can think of a spill methodology that has a gentle degradation
> curve, then I'm all for that. But I doubt there are any quick-hack
> improvements to be had here.
>
> regards, tom lane
--
P. J. "Josh" Rovero Sonalysts, Inc.
Email: rovero(at)sonalysts(dot)com www.sonalysts.com 215 Parkway North
Work: (860)326-3671 or 442-4355 Waterford CT 06385
***********************************************************************
From | Date | Subject | |
---|---|---|---|
Next Message | Frank van Vugt | 2004-12-07 13:35:34 | RC1, missing -lpthread when building with --disable-shared on i686 |
Previous Message | Stephan Szabo | 2004-12-07 12:26:37 | Re: Index scan vs. Seq scan on timestamps |