From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | David Ford <david(at)blue-labs(dot)org> |
Cc: | Calvin Dodge <caldodge(at)fpcc(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Problem w/ dumping huge table and no disk space |
Date: | 2001-09-08 09:01:00 |
Message-ID: | 20010908190100.B17777@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Sep 08, 2001 at 01:59:54AM -0400, David Ford wrote:
> On a side note (Tom, Bruce, etc), is there some way to mitigate psql's
> storage of all rows returned in memory? Perhaps a 'swap' file? If you
> connect to a 1.7G database and issue a query on it that returns a lot of
> rows, the entire thing is held in memory which with such a query is
> likely to cause an OOM and get killed.
psql does it because that's what the library does. I'm not sure if you can
get the library to return before all the rows have transferred. And if you
can someone needs to fix psql to use it.
pg_dump -d used to have this problem also but I recently submitted a patch
so that that doesn't happen anymore. I guess you could arrange for psql to
rewrite your SELECT statements to use a cursor but that may be unexpected...
--
Martijn van Oosterhout <kleptog(at)svana(dot)org>
http://svana.org/kleptog/
> Magnetism, electricity and motion are like a three-for-two special offer:
> if you have two of them, the third one comes free.
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2001-09-08 09:08:18 | Re: Abort state on duplicated PKey in transactions |
Previous Message | Justin Clift | 2001-09-08 07:26:32 | Re: [GENERAL] SQL Server to PostgreSQL HOWTO |