Skip site navigation (1) Skip section navigation (2)

Re: blobs

From: Steve Holdoway <steve(dot)holdoway(at)firetrust(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: blobs
Date: 2007-01-31 23:33:24
Message-ID: 20070201123324.c69e73f0.steve.holdoway@firetrust.com (view raw or flat)
Thread:
Lists: pgsql-admin
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" <phillip(dot)smith(at)weatherbeeta(dot)com(dot)au> 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: pgsql-admin-owner(at)postgresql(dot)org
> [mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Steve Holdoway
> Sent: Thursday, 1 February 2007 08:46
> To: pgsql-admin(at)postgresql(dot)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
> 

In response to

  • Re: blobs at 2007-01-31 22:25:08 from Phillip Smith

pgsql-admin by date

Next:From: Chad WagnerDate: 2007-01-31 23:45:15
Subject: Re: blobs
Previous:From: Andy Shellam (Mailing Lists)Date: 2007-01-31 22:57:38
Subject: Re: unsubscribe

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group