Hannu,
> RAID10
>
> "Throughput report Y-axis is type of test X-axis is number of processes"
> "Record size = 8 Kbytes "
> "Output is in ops/sec"
> " Initial write " 1352.90
> " Rewrite " 413.31
> RAID5
>
> "Throughput report Y-axis is type of test X-axis is number of processes"
> "Record size = 8 Kbytes "
> "Output is in ops/sec"
> " Initial write " 1178.55
> " Rewrite " 145.91
>
> Seems to have either very low overhead for RAID5 or something else is
> keeping RAID10 speed down.
The rewrite number is telling - the FPGA on the 3Ware card isn't doing XOR
while reading very well.
I've found that synthetic benchmarks aren't necessarily predictive for
Postgres performance. The issue is that the bottlenecks for writing data
and/or scans are not currently in the I/O subsystem. There are many
improvements to the executor and to the load/copy and DML paths necessary
before this is the case.
<begin flame bait :-), answers on bizgres-general>
So, I find that for data warehousing workloads (sequential access) if the
I/O subsystem runs faster than 100MB/s on sequential writes and about
120MB/s on scans, it will outrun Postgres anyway.
We're working to fix this, but right now it appears that high performance
I/O on one table (faster than 120MB/s) is not possible with a single
instance of Postgres.
<end flame bait>
Luke
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
