Ok, that makes perfect sense. We will upgrade to 64-bit and continue our tests on the new build.
By the way, is it safe to go ahead with Centos 5.5 or should we stick to the previous version 5.4?
Thank you so much Sam and Thom for your speedy help :)
Best regards,
Zeeshan
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Sam Mason
> Sent: 05 July 2010 15:14
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Out of memory on update of a single column table
> containg just one row.
>
> On Mon, Jul 05, 2010 at 01:52:20PM +0000,
> Zeeshan.Ghalib@globaldatapoint.com wrote:
> > So, is this there a restriction with 32-bit PostgreSQL, a bug or
> > configuration issue?
>
> It's a restriction because of the 32bit address space. You've
> basically
> got between two and three GB of useful space left and everything has to
> fit in there. Hence if you've got a 300MB object in memory (i.e. your
> XML) and you try and combine it with as similar sized object then
> you'll
> need 300MB*4 = 1.2GB of free memory in the process's address space,
> with
> 600MB of that being consecutive. It's obviously failing to find that
> and hence the query is failing. A 64bit address space is more than a
> million times larger and hence this is why that worked.
>
> Generally with databases you're expected to be working with lots of
> small objects (i.e. most a few bytes in length) with a few multi KB
> ones. Databases are fine with lots of these (i.e. I've got databases
> with hundreds of millions of rows) but don't work very well when each
> row is very big. The design assumption is that values are "atomic" and
> large values normally aren't atomic so would be broken down into
> smaller
> pieces when they enter the database.
>
> Maybe the large object functionality in PG would suit your needs
> better,
> they are designed for larger things like this and don't suffer the same
> restrictions (i.e. internally they're worked with piecemeal rather than
> trying to work with the whole thing in one go). They can be a bit of a
> hassle to work with, so which is "better" is very use case dependent.
>
> --
> Sam http://samason.me.uk/
>
> p.s. the legalese at the bottom of your emails is probably dissuading
> a number of people from replying, you're better off dumping it if you
> can--it serves no useful purpose anyway.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
This e-mail is confidential and should not be used by anyone who is not the original intended recipient. Global
DataPointLimited does not accept liability for any statements made which are clearly the sender's own and not expressly
madeon behalf of Global DataPoint Limited. No contracts may be concluded on behalf of Global DataPoint Limited by means
ofe-mail communication. Global DataPoint Limited Registered in England and Wales with registered number 3739752
RegisteredOffice Middlesex House, 34-42 Cleveland Street, London W1T 4LB