Re: [PERFORM] Zeus IOPS
On Fri, 2010-05-28 at 13:48 -0600, Scott Marlowe wrote: Anybody on the list have any experience with these drives? They get good numbers but I can't find diddly on them on the internet for the last year or so. http://www.stec-inc.com/product/zeusiops.php I'd heard that they were a popular choice in the Enterprise market, but that was around 6 months ago or so, and purely anecdotal. Seems strange though for them to disappear off the radar when SSD related information is becoming so prevalent. That could just be an effect of all the noise around the non-Enterprise grade SSD's floating around though. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp. -- 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] Zeus IOPS
On Mon, May 31, 2010 at 7:06 AM, Brad Nicholson bnich...@ca.afilias.info wrote: On Fri, 2010-05-28 at 13:48 -0600, Scott Marlowe wrote: Anybody on the list have any experience with these drives? They get good numbers but I can't find diddly on them on the internet for the last year or so. http://www.stec-inc.com/product/zeusiops.php I'd heard that they were a popular choice in the Enterprise market, but that was around 6 months ago or so, and purely anecdotal. Seems strange though for them to disappear off the radar when SSD related information is becoming so prevalent. That could just be an effect of all the noise around the non-Enterprise grade SSD's floating around though. Yeah. According to a buddy of mine they're mostly only resold by Sun and EMC in their own products. Of course what I'm really looking for are postive stories about them surviving power plug pulls without corrupting the database. -- 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] planner costs in warm cache tests
On 2010-05-30 20:34, Tom Lane wrote: Jesper Kroghjes...@krogh.cc writes: testdb=# set seq_page_cost = 0.1; SET testdb=# set random_page_cost = 0.1; SET Well, hmm, I really doubt that that represents reality either. A page access is by no means free even when the page is already in cache. I don't recall anyone suggesting that you set these numbers to less than perhaps 0.01. Thank you for the prompt response. Is it a false assumption that the cost should in some metric between different plans be a measurement of actual run-time in a dead-disk run? It should most likely be matching a typical workload situation, but that it really hard to tell anything about, so my feeling would be that the dead disk case is the one closest? -- Jesper -- 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] planner costs in warm cache tests
Jesper Krogh jes...@krogh.cc writes: On 2010-05-30 20:34, Tom Lane wrote: Well, hmm, I really doubt that that represents reality either. A page access is by no means free even when the page is already in cache. I don't recall anyone suggesting that you set these numbers to less than perhaps 0.01. Thank you for the prompt response. Is it a false assumption that the cost should in some metric between different plans be a measurement of actual run-time in a dead-disk run? Well, the default cost parameters (seq_page_cost=1, random_page_cost=4) are intended to model the non-cached state where most page fetches actually do require a disk access. They are definitely too large relative to the cpu_xxx_cost parameters when you have a fully-cached database, but what I've seen people recommending for that condition is to set them both to the same value in the vicinity of 0.1 or 0.01 or so. If it's only mostly cached you might try intermediate settings. 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
