From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: AW: Proposal: More flexible backup/restore via pg_dump |
Date: | 2000-06-27 15:08:03 |
Message-ID: | 3.0.5.32.20000628010803.0226f100@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 10:48 27/06/00 -0400, Tom Lane wrote:
>
>Right, the thing we *really* want is to preserve the fact that pg_dump
>can write its output to a pipeline ... and that a restore can read from
>one. If you can improve performance when you find you do have a
>seekable source/destination file, fine, but the utilities must NOT
>require it.
OK, the limitation will have to be that reordering of *data* loads (as
opposed to metadata) will not be possible in piped data. This is only a
problem if RI constraints are loaded.
I *could* dump the compressed data to /tmp, but I would guess that in most
cases when the archive file is being piped it's because the file won't fit
on a local disk.
Does this sound reasonable?
>> I guess we would want two formats, one for pipe, and one for a standard
>> directory.
>
>At the risk of becoming tiresome, "tar" format is eminently pipeable...
>
No, it's good...I'll never feel guilty about asking for optimizer hints again.
More seriously, though, if I pipe a tar file, I still can't reorder the
*data* files without saving them to disk, which is what I want to avoid.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-27 15:15:01 | Re: AW: SQL99 functions |
Previous Message | Thomas Lockhart | 2000-06-27 15:07:31 | Re: AW: SQL99 functions |