From: Tom Lane <tgl@sss.pgh.pa.us>
To: Surafel Temesgen <surafel3000@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_dump multi VALUES INSERT
In-reply-to: 
 <CALAY4q9kumSdnRBzvRJvSRf2+BH20YmSvzqOkvwpEmodD-xv6g@mail.gmail.com>
References: 
 <CALAY4q9kumSdnRBzvRJvSRf2+BH20YmSvzqOkvwpEmodD-xv6g@mail.gmail.com>
Comments: In-reply-to Surafel Temesgen <surafel3000@gmail.com>
	message dated "Tue, 16 Oct 2018 19:17:11 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <27170.1539719339.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 16 Oct 2018 15:48:59 -0400
Message-ID: <27171.1539719339@sss.pgh.pa.us>
Precedence: bulk

Surafel Temesgen <surafel3000@gmail.com> writes:
> According to the documentation –inserts 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 values
> insert command are equally portable and compact and also faster to reload
> than single row statement. I think it deserve an option of its own

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.

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.

			regards, tom lane