Availability of hardware monitoring software, and my personally being sick of things falling over. I have to run Mysql 4.0 on this server at the moment, and wasn't prepared to take the risk (:
Maybe by the time we implement, 64 bit will be reliable enough. Steve On Thu, 1 Feb 2007 09:25:08 +1100 "Phillip Smith" <[EMAIL PROTECTED]> wrote: > I don't know about your table question, but may I ask why you're running > 32-bit when you have dual Xeon processors? > > I have dual Xeon's in my DWH, and I used to run 32-bit which I upgraded to > 64-bit over Christmas. We run a nightly import to that database which used > to take around 5 hours which now completes in less than 1 hour. > > Many of our large queries also run much faster - the only thing I did was > reload the box with RedHat ES 4 64-bit instead of 32-bit. > > My 2.2 cents (Aust. GST inclusive!) > > Cheers, > -p > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Holdoway > Sent: Thursday, 1 February 2007 08:46 > To: pgsql-admin@postgresql.org > Subject: [ADMIN] blobs > > I'm got the enviable task of redesigning an MySQL based project from > scratch. We need a proper rdbms for this project, and I want to use PG 8.2. > > The table I'm concerned with at the moment have (currently) 5 million rows, > with a churn of about 300,000 rows a week. The table has about a million > hits a day, which makes it the main potential bottleneck in this database. > > We need to store some large ( 0 -> 100kB ) data with each row. Would you > recommend adding it as columns in this table, given that blobs will be > stored in the pg_largeobject table anyway, or would you recommend a daughter > table for this? > > Any other suggestions on how to avoid performance problems with this table ( > hardware is dual Xeon, 4GB mem, 2 hardware raid channels for storage + 1 for > logs, all running debian 32 bit ). > > Cheers, > > Steve > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > > > *******************Confidentiality and Privilege Notice******************* > > The material contained in this message is privileged and confidential to > the addressee. If you are not the addressee indicated in this message or > responsible for delivery of the message to such person, you may not copy > or deliver this message to anyone, and you should destroy it and kindly > notify the sender by reply email. > > Information in this message that does not relate to the official business > of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. > Weatherbeeta, its employees, contractors or associates shall not be liable > for direct, indirect or consequential loss arising from transmission of this > message or any attachments > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
