Re: [PERFORM] Advice configuring ServeRAID 8k for performance
On Thu, 5 Aug 2010, Scott Marlowe wrote: RAID6 is basically RAID5 with a hot spare already built into the array. On Fri, 6 Aug 2010, Pierre C wrote: As others said, RAID6 is RAID5 + a hot spare. No. RAID6 is NOT RAID5 plus a hot spare. RAID5 uses a single parity datum (XOR) to ensure protection against data loss if one drive fails. RAID6 uses two different sets of parity (Reed-Solomon) to ensure protection against data loss if two drives fail simultaneously. If you have a RAID5 set with a hot spare, and you lose two drives, then you have data loss. If the same happens to a RAID6 set, then there is no data loss. Matthew -- And the lexer will say Oh look, there's a null string. Oooh, there's another. And another., and will fall over spectacularly when it realises there are actually rather a lot. - Computer Science Lecturer (edited) -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Advice configuring ServeRAID 8k for performance
On Fri, Aug 6, 2010 at 3:17 AM, Matthew Wakeling matt...@flymine.org wrote: On Thu, 5 Aug 2010, Scott Marlowe wrote: RAID6 is basically RAID5 with a hot spare already built into the array. On Fri, 6 Aug 2010, Pierre C wrote: As others said, RAID6 is RAID5 + a hot spare. No. RAID6 is NOT RAID5 plus a hot spare. The original phrase was that RAID 6 was like RAID 5 with a hot spare ALREADY BUILT IN. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Advice configuring ServeRAID 8k for performance
On Fri, Aug 6, 2010 at 11:32 AM, Justin Pitts justinpi...@gmail.com wrote: As others said, RAID6 is RAID5 + a hot spare. No. RAID6 is NOT RAID5 plus a hot spare. The original phrase was that RAID 6 was like RAID 5 with a hot spare ALREADY BUILT IN. Built-in, or not - it is neither. It is more than that, actually. RAID 6 is like RAID 5 in that it uses parity for redundancy and pays a write cost for maintaining those parity blocks, but will maintain data integrity in the face of 2 simultaneous drive failures. Yes, I know that. I am very familiar with how RAID6 works. RAID5 with the hot spare already rebuilt / built in is a good enough answer for management where big words like parity might scare some PHBs. In terms of storage cost, it IS like paying for RAID5 + a hot spare, but the protection is better. A RAID 5 with a hot spare built in could not survive 2 simultaneous drive failures. Exactly. Which is why I had said with the hot spare already built in / rebuilt. Geeze, pedant much? -- To understand recursion, one must first understand recursion. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] vacuum performance on insert
hi, thank you for the reply. I ran a number of tests to try to make sense of this. When I ran with or without vacuum, the number of disk io operations, cache operations etc. gathered from pg_stat table for the insertions are pretty much the same. So I don't see vacuum reduce disk io operations. Now from what you mentioned below, do you know what's the cost of postgres requesting new disk space from OS? I'm seeing a big performance difference with vacuum, but I need a proof to show it's the requesting new space operation that was the problem, not disk io, etc. since I would think disk could be expensive as well. Thanks, Sean On Thu, Aug 5, 2010 at 2:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Sean Chen zysc...@gmail.com 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 statements would allow the INSERT to re-use the space previously occupied by the deleted rows, rather than possibly needing to allocate new space from the OS. But on the other side of the coin, the ANALYZE step is probably not very helpful there. Better to do that after you've loaded the new data. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
