On 06/08/10 12:31, Mark Kirkwood wrote:
On 06/08/10 11:58, Alan Hodgson wrote:
On Thursday, August 05, 2010, Mark
Kirkwood
wrote:
Normally I'd agree with the others and recommend RAID10 - but you say
you have an OLAP workload - if it is *heavily* read biased you may get
better performance with
On 06/08/10 11:58, Alan Hodgson wrote:
On Thursday, August 05, 2010, Mark Kirkwood
wrote:
Normally I'd agree with the others and recommend RAID10 - but you say
you have an OLAP workload - if it is *heavily* read biased you may get
better performance with RAID5 (more effective disks to read f
On Thursday, August 05, 2010, Mark Kirkwood
wrote:
> Normally I'd agree with the others and recommend RAID10 - but you say
> you have an OLAP workload - if it is *heavily* read biased you may get
> better performance with RAID5 (more effective disks to read from).
> Having said that, your sequent
On 06/08/10 06:28, Kenneth Cox wrote:
I am using PostgreSQL 8.3.7 on a dedicated IBM 3660 with 24GB RAM
running CentOS 5.4 x86_64. I have a ServeRAID 8k controller with 6
SATA 7500RPM disks in RAID 6, and for the OLAP workload it feels*
slow. I have 6 more disks to add, and the RAID has to be
On Thu, Aug 5, 2010 at 5:13 PM, Dave Crooke wrote:
> Definitely switch to RAID-10 it's not merely that it's a fair bit
> faster on normal operations (less seek contention), it's **WAY** faster than
> any parity based RAID (RAID-2 through RAID-6) in degraded mode when you lose
> a disk and hav
Definitely switch to RAID-10 it's not merely that it's a fair bit
faster on normal operations (less seek contention), it's **WAY** faster than
any parity based RAID (RAID-2 through RAID-6) in degraded mode when you lose
a disk and have to rebuild it. This is something many people don't test fo
On Thu, Aug 5, 2010 at 4:27 PM, Pierre C wrote:
>
>> 1) Should I switch to RAID 10 for performance? I see things like "RAID 5
>> is bad for a DB" and "RAID 5 is slow with <= 6 drives" but I see little on
>> RAID 6.
>
> As others said, RAID6 is RAID5 + a hot spare.
>
> Basically when you UPDATE a
On 8/5/10 11:28 AM, Kenneth Cox wrote:
I am using PostgreSQL 8.3.7 on a dedicated IBM 3660 with 24GB RAM
running CentOS 5.4 x86_64. I have a ServeRAID 8k controller with 6 SATA
7500RPM disks in RAID 6, and for the OLAP workload it feels* slow
My current performance is 85MB/s write, 151 MB/s
1) Should I switch to RAID 10 for performance? I see things like "RAID
5 is bad for a DB" and "RAID 5 is slow with <= 6 drives" but I see
little on RAID 6.
As others said, RAID6 is RAID5 + a hot spare.
Basically when you UPDATE a row, at some point postgres will write the
page which con
Kenneth Cox wrote:
1) Should I switch to RAID 10 for performance? I see things like
"RAID 5 is bad for a DB" and "RAID 5 is slow with <= 6 drives" but I
see little on RAID 6. RAID 6 was the original choice for more usable
space with good redundancy. My current performance is 85MB/s write,
1
On Thu, Aug 5, 2010 at 12:28 PM, Kenneth Cox wrote:
> I am using PostgreSQL 8.3.7 on a dedicated IBM 3660 with 24GB RAM running
> CentOS 5.4 x86_64. I have a ServeRAID 8k controller with 6 SATA 7500RPM
> disks in RAID 6, and for the OLAP workload it feels* slow. I have 6 more
> disks to add, and
On Thursday, August 05, 2010, "Kenneth Cox" wrote:
> 1) Should I switch to RAID 10 for performance? I see things like "RAID 5
> is bad for a DB" and "RAID 5 is slow with <= 6 drives" but I see little
> on RAID 6. RAID 6 was the original choice for more usable space with
> good redundancy. My cu
I can query either my PARENT table joined to PRICES, or my VERSION table joined
to PRICES, and get an answer in 30-40 msec. But put the two together, it jumps
to 4 seconds. What am I missing here? I figured this query would be nearly
instantaneous. The VERSION.ISOSMILES and PARENT.ISOSMILES
I am using PostgreSQL 8.3.7 on a dedicated IBM 3660 with 24GB RAM running
CentOS 5.4 x86_64. I have a ServeRAID 8k controller with 6 SATA 7500RPM
disks in RAID 6, and for the OLAP workload it feels* slow. I have 6 more
disks to add, and the RAID has to be rebuilt in any case, but first I
"Kevin Grittner" writes:
> Sean Chen wrote:
>> 1, delete records ...
>> 2, insert records ...
>>
>> if I add "vacuum analyze" in-between this two steps, will it help
>> on the performance on the insert?
> Assuming there are no long-running transactions which would still be
> able to see the de
Sean Chen wrote:
> 1, delete records ...
> 2, insert records ...
>
> if I add "vacuum analyze" in-between this two steps, will it help
> on the performance on the insert?
Assuming there are no long-running transactions which would still be
able to see the deleted rows, a VACUUM between those
Hi, I'm curious -- does "vacuum analyze e.g. table1" improve
performance on "insert into table1 ...". I understand the vacuum
analyze helps out the query -- select, etc., but just not quite sure
on insert.
Specifically, I'm doing the following.
1, delete records ...
2, insert records ...
if I ad
On 10-08-04 03:49 PM, Scott Carey wrote:
On Aug 2, 2010, at 7:26 AM, Merlin Moncure wrote:
On Fri, Jul 30, 2010 at 11:01 AM, Yeb Havinga wrote:
After a week testing I think I can answer the question above: does it work
like it's supposed to under PostgreSQL?
YES
The drive I have tested is
18 matches
Mail list logo
