From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com> |
Cc: | "Stephen Lawrence Jr(dot)" <logart(at)mail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: disk backups |
Date: | 2000-06-29 15:03:11 |
Message-ID: | 531.962290991@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com> writes:
> Is there a better way? Here pg_dumping the DB takes over half an hour
> (mainly because pg_dump chews all available memory).
pg_dump shouldn't be a performance hog if you are using the default
COPY-based style of data export. I'd only expect memory problems
if you are using INSERT-based export (-d or -D switch to pg_dump).
For now, the answer is "don't do that" ... at least not on big tables.
This could be fixed in either of two ways:
1. recode pg_dump to use DECLARE CURSOR and FETCH to grab table contents
in reasonable-size chunks (instead of with an all-at-once SELECT);
2. add an API to libpq that allows a select result to be retrieved
on-the-fly rather than accumulating it in libpq's memory.
The second is more work but would be more widely useful.
However, it's not been much of a priority, since insert-based data
export is so slow to reload that no sensible person uses it for
big tables anyway ;-)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-29 16:09:10 | Re: NOTICE messages during table drop |
Previous Message | Tom Lane | 2000-06-29 14:52:28 | Re: Importing data w/ Unix timestamp |