From: Dimitri Fontaine <dfontaine@hi-media.com>
Organization: Hi-Media
To: pgsql-performance@postgresql.org
Subject: Re: Benchmark Data requested
Date: Tue, 5 Feb 2008 18:01:50 +0100
User-Agent: KMail/1.9.7
Cc: Simon Riggs <simon@2ndquadrant.com>, Richard Huxton <dev@archonet.com>,
	"Jignesh K. Shah" <J.K.Shah@sun.com>, Greg Smith <gsmith@gregsmith.com>
References: <1202150236.4252.521.camel@ebony.site>
	<47A87B2E.7050205@archonet.com>
	<1202225207.4252.718.camel@ebony.site>
In-Reply-To: <1202225207.4252.718.camel@ebony.site>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1859105.Nv4HRCDryA";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200802051801.52963.dfontaine@hi-media.com>

--nextPart1859105.Nv4HRCDryA
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le mardi 05 f=C3=A9vrier 2008, Simon Riggs a =C3=A9crit=C2=A0:
> It runs a stream of COPY statements, so only first would be optimized
> with the "empty table optimization".

The number of rows per COPY statement is configurable, so provided you have=
 an=20
estimation of the volume to import (wc -l), you could tweak this number for=
=20
lowering the stream (down to 1 COPY maybe)...

But basically a COPY run should be kept in memory (and we're talking about=
=20
high volumes here) and in case of error processing you'd want it not that=20
huge after all...

=2D-=20
dim

--nextPart1859105.Nv4HRCDryA
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHqJaAlBXRlnbh1bkRAoZMAJ9S1psn6A/9K7KFr8szVJRPWaOw3QCeLRv2
vCwrzSV4kqRBk9uUwN+ZIKE=
=KCdi
-----END PGP SIGNATURE-----

--nextPart1859105.Nv4HRCDryA--