Ok thanks.
iostat confirmed it's an IO bottleneck.
Will add some discs to the RAID unit.
Used 4 Raptor discs in Raid 10 until now.
best regards,
patric
Tom Lane wrote:
Patric de Waha <[EMAIL PROTECTED]> writes:
Postgres is running on a dedicated server P4 DualCore, 4 Gig Ram.
When you don't even mention your disk hardware, that's a bad sign.
In a database server the disk is usually more important than the CPU.
Why do long readers influence the rest of the transactions in such a
heavy way?
Any configuration changes which can help here?
Is it a disc-IO bottleneck thing?
Very possibly. Have you spent any time watching "vmstat 1" output
to get a sense of whether your I/O is saturated?
WAL files are located on another disc than the dbase itself.
That's good, but it only relates to update performance not SELECT
performance.
effective_cache_size = 5000
That's way too small for a 4G machine. You could probably stand to
boost maintenance_work_mem too. However, neither of these have any
immediate relationship to your problem.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
