| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Luke Lonergan <llonergan(at)greenplum(dot)com> |
| 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 21:19:25 |
| Message-ID: | 20051202211925.GF6026@ns.snowman.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
* Luke Lonergan (llonergan(at)greenplum(dot)com) wrote:
> 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.
I've used the binary mode stuff before, sure, Postgres may have to
convert some things but I have a hard time believing it'd be more
expensive to do a network_encoding -> host_encoding (or toasting, or
whatever) than to do the ascii -> binary change.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2005-12-02 21:24:31 | Re: Database restore speed |
| Previous Message | Andrew Sullivan | 2005-12-02 21:08:56 | Re: 15,000 tables |