Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154] (may be forged)) by hub.org (8.10.1/8.10.1) with ESMTP id e8MGWDs25378 for ; Fri, 22 Sep 2000 12:32:13 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.0/8.11.0) with ESMTP id e8MGVvB29423; Fri, 22 Sep 2000 12:31:57 -0400 (EDT) To: Thomas Lockhart cc: "Kirby Bohling (TRSi)" , pgsql-interfaces@postgresql.org Subject: Re: cursor interface to libpq In-reply-to: <39C8E45C.AE72C336@alumni.caltech.edu> References: <39C8E45C.AE72C336@alumni.caltech.edu> Comments: In-reply-to Thomas Lockhart message dated "Wed, 20 Sep 2000 16:22:52 -0000" Date: Fri, 22 Sep 2000 12:31:57 -0400 Message-ID: <29420.969640317@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200009/95 Thomas Lockhart writes: > afaik this should all work. You can run pg_dump and pipe the output to a > tape drive or to gzip. You *know* that a real backup will take something > like the size of the database (maybe a factor of two or so less) since > the data has to go somewhere. pg_dump in default mode (ie, dump data as COPY commands) doesn't have a problem with huge tables because the COPY data is just dumped out in a streaming fashion. If you insist on using the "dump data as insert commands" option then huge tables cause a memory problem in pg_dump, but on the other hand you are going to get pretty tired of waiting for such a script to reload, too. I recommend just using the default behavior ... regards, tom lane