Date: Wed, 17 Oct 2018 15:05:28 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Surafel Temesgen <surafel3000@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_dump multi VALUES INSERT
Message-ID: <20181017190528.GD4184@tamriel.snowman.net>
References: 
 <CALAY4q9kumSdnRBzvRJvSRf2+BH20YmSvzqOkvwpEmodD-xv6g@mail.gmail.com>
 <27171.1539719339@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="iqA+W5SgHj++dmBm"
Content-Disposition: inline
In-Reply-To: <27171.1539719339@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--iqA+W5SgHj++dmBm
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Surafel Temesgen <surafel3000@gmail.com> writes:
> > According to the documentation =E2=80=93inserts option is mainly useful=
 for making
> > dumps that can be loaded into non-PostgreSQL databases and to reduce the
> > amount of rows that might lost during error in reloading but multi valu=
es
> > insert command are equally portable and compact and also faster to relo=
ad
> > than single row statement. I think it deserve an option of its own
>=20
> I don't actually see the point of this.  If you want dump/reload speed
> you should be using COPY.  If that isn't your first priority, it's
> unlikely that using an option like this would be a good idea.  It makes
> the effects of a bad row much harder to predict, and it increases your
> odds of OOM problems with wide rows substantially.
>=20
> I grant that COPY might not be an option if you're trying to transfer
> data to a different DBMS, but the other problems seem likely to apply
> anywhere.  The bad-data hazard, in particular, is probably a much larger
> concern than it is for Postgres-to-Postgres transfers.

I can't say that I can really buy off on this argument.

The point of it is that it makes loading into other RDBMS faster.  Yes,
it has many of the same issues as our COPY does, but we support it
because it's much faster.  The same is true here, just for other
databases, so I'm +1 on the general idea.

I've not looked at the patch itself at all, yet.

Thanks!

Stephen

--iqA+W5SgHj++dmBm
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJbx4f4AAoJEO1sijiDR2RVvZYP/Rm6Bo9kpgyLSKiYTSuVHgOU
DkPbgZfic9pSoPV1d9YsLZU9upsD/3SjixP9DhJLoAHNlw3agiBRHO/tH/0sT4Rw
dxhqefkPVvnFfAoQQVlb/hRuGgWSsBJS1gONBM++csTvU6lhwa2VBUppsDK9HnGg
d+Ai04BHK2XqMhYq+BnsJjqqAewL7PMiA5ztanYOODq8oKDgKogtz3DEaIJZ+pKD
kgbVQ7Vj4J4j24z7/FcBLAZPeIFelGz1ELyxtMIYUaf8sRBBn3XI5NWh/LH/MkzM
i76PqTOk9Me5dz4rwbb01sKA05rT77IbLKw0ifbgXIiyhIYFL4Je+1crhPQ37BIu
PlTLyVzP524q42gxJ6vVkOF2sqBl0WtHh0lzimyT63JCKlSw/uFFtDC4Uvov+hAQ
sneGMXgatYtdlJ+63T3aqISM4wP1J11hF0Ul7kP49xQX29mcSkhH/bB611YEn4Nh
xnXM18KjbqLg0EX1dfmey1DvE6kig5PFlncJAH1QzxwphThf6oFE6D7IMwtnUTNo
hyMeUstz+C5MXv6g2Kp1gOco4tICbUTTdStdsqSdwzp8d5Slhb74JW5JIBRbELcB
czUNvQFZrRb2XbR8WYkWWyHVUM5fMTzrooKV4m0RZkND3kCvC6Zj7apCpZkAB+BK
eVvQ8MbolwsyLImyeyFK
=glfE
-----END PGP SIGNATURE-----

--iqA+W5SgHj++dmBm--