If you are using ext3, your performance on the RAID card may also improve if
the postgres xlog is not on the same partition as the data. Otherwise, for
every transaction commit, all of the data on the whole partition will have to
be sync()'d not just the xlog.
Also, what is the performance dif
> That said, a look into the write-caching+BBU policy on your controller is
> worthwhile. If you're running this application successfully on some
> hardware but not others, that could be a source for the difference.
>
I think it's really a BBU/BBWC problem.
The tests that we made in the lab with
Daniel Ferreira de Lima wrote:
> **Both with Linux Kernel 2 .4.37.9 and Postgresql 7.2**
Wow. You really need to upgrade.
Yes, but unfortunately, actually it's impossible and economically
inviable...
Generally, getting good performance out of PostgreSQL 7.2 is also
impossible
> > **Both with Linux Kernel 2 .4.37.9 and Postgresql 7.2**
>
> Wow. You really need to upgrade.
>
Yes, but unfortunately, actually it's impossible and economically
inviable...
> > Under a insertion test we get a performance of 2.5 secs under 2000
> > inserts (table with a single char(50) col
Daniel Ferreira de Lima wrote:
> **Both with Linux Kernel 2 .4.37.9 and Postgresql 7.2**
Wow. You really need to upgrade.
> Under a insertion test we get a performance of 2.5 secs under 2000
> inserts (table with a single char(50) column) in the IDE disk.
> And 500GB RAID 0 (4 disks!) and 3
Hi people,
I have a particular performance problem under a system installed.
In the lab I have an old Microside + Dual Core machine 1GB RAM with 40gb HD
IDE and
a newer machine HP DL 380 G5 4GB RAM and 500GB SAS under RAID 0 (4 disks)
P400i Smart Array Controller.
**Both with Linux Kernel 2 .4.3
