From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Igor Neyman <ineyman(at)perceptron(dot)com> |
Subject: | Re: Parallel pg_restore versus old dump files |
Date: | 2010-06-23 10:20:23 |
Message-ID: | AANLkTinTdw4jk3fc1wryWTGASjMVCWMkWwB_ROJcm51n@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 23, 2010 at 2:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Uh, that doesn't fix anything: if you can't seek, a TOC at the end of
> the file is useless. And the cases where the writer can't seek are
> likely to be identically the ones where the reader can't seek, viz
> pg_dump piped to pg_restore (perhaps with some other programs between).
That seems like a tenuous leap. A typical reason for the pipe is to
transfer it to a different machine and that only has to be done once.
But I'm not convinced it's such a great idea either for the reason I
described -- It makes the case where pg_restore has to read through
the whole archive that much harder to explain to users. So I'm not
really going to argue for it too strongly. It's also a fair amount of
extra complexity for not much gain. We would still need the fallback
code anyways.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-06-23 11:17:12 | Re: testing plpython3u on 9.0beta2 |
Previous Message | Magnus Hagander | 2010-06-23 09:37:28 | Re: Parallel pg_restore versus old dump files |