On Mon, Jul 05, 2010 at 01:52:20PM +0000, zeeshan.gha...@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
