On Mon, 2003-12-08 at 11:19, Tom Lane wrote:
> Jack Coates <jack@lyris.com> writes:
> > Theories at this point, in no particular order:
>
> > a) major differences between my 7.3.4 from source (compiled with no
> > options) and dev's 7.3.2-1PGDG RPMs. Looking at the spec file doesn't
> > reveal anything glaring to me, but is there something I'm missing?
>
> There are quite a few performance-related patches between 7.3.2 and
> 7.3.4. Most of them should be in 7.3.4's favor but there are some
> places where we had to take a performance hit in order to have a
> suitably low-risk fix for a bug. You haven't told us enough about
> the problem to know if any of those cases apply, though. AFAIR
> you have not actually showed either the slow query or EXPLAIN ANALYZE
> results for it on the two boxes ...
>
> regards, tom lane
Right, because re-architecture of a cross-platform query makes sense if
performance is bad on all systems, but is questionable activity when
performance is fine on some systems and lousy on others. Hence my
statement that while SQL optimization is certainly something we want to
do for across-the-board performance increase, I wanted to focus on other
issues for troubleshooting this problem. I will be back to ask about
data access models later :-)
I ended up going back to a default postgresql.conf and reapplying the
various tunings one-by-one. Turns out that while setting fsync = false
had little effect on the slow IDE box, it had a drastic effect on this
faster SCSI box and performance is quite acceptable now (aside from the
expected falloff of about 30% after the first twenty minutes, which I
believe comes from growing and shrinking tables without vacuumdb
--analyzing).
--
Jack Coates, Lyris Technologies Applications Engineer
510-549-4350 x148, jack@lyris.com
"Interoperability is the keyword, uniformity is a dead end."
--Olivier Fourdan