From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Stephen Frost" <sfrost(at)snowman(dot)net> |
Cc: | "David Lang" <dlang(at)invendra(dot)net>, "Steve Oualline" <soualline(at)stbernard(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Database restore speed |
Date: | 2005-12-02 20:48:08 |
Message-ID: | BFB5F308.14E82%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Stephen,
On 12/2/05 12:18 PM, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
> Just a thought, but couldn't psql be made to use the binary mode of
> libpq and do at least some of the conversion on the client side? Or
> does binary mode not work with copy (that wouldn't suprise me, but
> perhaps copy could be made to support it)?
Yes - I think this idea is implicit in what David suggested, and my response
as well. The problem is that the way the client does conversions can
potentially differ from the way the backend does. Some of the types in
Postgres are machine intrinsic and the encoding conversions use on-machine
libraries, each of which preclude the use of client conversion methods
(without a lot of restructuring). We'd tackled this problem in the past and
concluded that the parse / convert stage really belongs in the backend.
> The other thought, of course, is that you could use PITR for your
> backups instead of pgdump...
Totally - great idea, if this is actually a backup / restore then PITR plus
filesystem copy (tarball) is hugely faster than dump / restore.
- Luke
From | Date | Subject | |
---|---|---|---|
Next Message | Josep Maria Pinyol Fontseca | 2005-12-02 21:08:27 | Re: Network permormance under windows |
Previous Message | Qingqing Zhou | 2005-12-02 20:43:34 | Re: Network permormance under windows |