User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Fri, 02 Dec 2005 13:29:47 -0800
Subject: Re: Database restore speed
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Stephen Frost" <sfrost@snowman.net>
cc: "David Lang" <dlang@invendra.net>,
	"Steve Oualline" <soualline@stbernard.com>,
	pgsql-performance@postgresql.org
Message-ID: <BFB5FCCB.14EA8%llonergan@greenplum.com>
Thread-Topic: [PERFORM] Database restore speed
Thread-Index: AcX3hgX4DADgfrd4RAWuo4H4HBe4FgAAMJyIAAAvFrE=
In-Reply-To: <BFB5FB8F.14EA1%llonergan@greenplum.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen,

On 12/2/05 1:19 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
> 
>> 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.
> 
> From a performance standpoint no argument, although you're betting that you
> can do parsing / conversion faster than the COPY core in the backend can (I
> know *we* can :-).  It's a matter of safety and generality - in general you
> can't be sure that client machines / OS'es will render the same conversions
> that the backend does in all cases IMO.

One more thing - this is really about the lack of a cross-platform binary
input standard for Postgres IMO.  If there were such a thing, it *would* be
safe to do this.  The current Binary spec is not cross-platform AFAICS, it
embeds native representations of the DATUMs, and does not specify a
universal binary representation of same.

For instance - when representing a float, is it an IEEE 32-bit floating
point number in little endian byte ordering? Or is it IEEE 64-bit?  With
libpq, we could do something like an XDR implementation, but the machinery
isn't there AFAICS.

- Luke