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!)
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Steve Holdoway
Sent: Thursday, 1 February 2007 08:46
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 ).
---------------------------(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
*******************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
In response to
- blobs at 2007-01-31 21:46:06 from Steve Holdoway
- Re: blobs at 2007-01-31 23:33:24 from Steve Holdoway
pgsql-admin by date
|Next:||From: Andy Shellam (Mailing Lists)||Date: 2007-01-31 22:57:38|
|Subject: Re: unsubscribe|
|Previous:||From: GURON Rawender||Date: 2007-01-31 22:13:46|