Re: disk backups

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

In response to

Responses

Browse pgsql-general by date

  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