Feedback-ID: id4a34324:Fastmail
Date: Sun, 05 Feb 2023 21:52:33 -0800
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>, Damir Belyalov <dam.bel07@gmail.com>
CC: Danil Anisimow <anisimow.d@gmail.com>,
 "HukuToc@gmail.com" <HukuToc@gmail.com>,
 torikoshia <torikoshia@oss.nttdata.com>,
 "a.lepikhov@postgrespro.ru" <a.lepikhov@postgrespro.ru>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
User-Agent: K-9 Mail for Android
In-Reply-To: <2587470.1675660337@sss.pgh.pa.us>
References: <CALH1Lgv5QeYSWYDgMBd=wvKum8egiaMR-_77VGsiHPt7E8dK9Q@mail.gmail.com> <CALH1LgvzpORM+EHVXRz4-Dv+_aHvm9m9Hu6eYM4PfppwKgXvFQ@mail.gmail.com> <686e46d6718f9535bc39fac7cad7408b@oss.nttdata.com> <CALH1Lgsr7Asz6r6jnRta7DVEjKwyz=b3XJhyCMoYv8Yy9y4cXg@mail.gmail.com> <769423519e16d18a1e7611c6931da58b@oss.nttdata.com> <CALH1LguQ5P0uZSYQFy4gJihvV11EkLx+gwxZ-+1DFq1Z6dJqbg@mail.gmail.com> <CALH1Lgug+mR9A1bBzR8hrp2oW4=jvR_N0An-i2X_j_y9C1fkiA@mail.gmail.com> <CALH1LguPAN=p5wHKwGcHrjE8Vj1x4o1z3Pk228YDif6LFzbeYQ@mail.gmail.com> <CABm2Ma6_=qf7kZPyOmiK1CUXeio7q08HNPYXrqkCwF3P_KQu7A@mail.gmail.com> <CALH1Lgv+L_HNN2NKo=WD8BbgLy7tEH7=OhNTJ2QWCU_CPMum0g@mail.gmail.com> <20230205233723.xw5z5zmeyc57ezq3@alap3.anarazel.de> <CALH1LgsbWZWS3qMxdGjg4n57DUHxqyBgTzvYSzfi-sP1N-ZORQ@mail.gmail.com> <2587470.1675660337@sss.pgh.pa.us>
Message-ID: <483E1B59-4A80-450B-8685-7CC12762FD5A@anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/483E1B59-4A80-450B-8685-7CC12762FD5A%40anarazel.de>
Precedence: bulk

Hi,=20

On February 5, 2023 9:12:17 PM PST, Tom Lane <tgl@sss=2Epgh=2Epa=2Eus> wro=
te:
>Damir Belyalov <dam=2Ebel07@gmail=2Ecom> writes:
>>> I don't think this is the right approach=2E Creating a subtransaction =
for
>>> each row will cause substantial performance issues=2E
>
>> Subtransactions aren't created for each row=2E The block of rows in one
>> subtransaction is 1000 (SAFE_BUFFER_SIZE) and can be changed=2E
>
>I think that at this point, any patch that involves adding subtransaction=
s
>to COPY is dead on arrival; whether it's batched or not is irrelevant=2E
>(It's not like batching has no downsides=2E)

Indeed=2E

>> InputFunctionCallSafe() is good for detecting errors from input-functio=
ns
>> but there are such errors from NextCopyFrom () that can not be detected
>> with InputFunctionCallSafe(), e=2Eg=2E "wrong number of columns in row'=
'=2E
>
>If you want to deal with those, then there's more work to be done to make
>those bits non-error-throwing=2E  But there's a very finite amount of cod=
e
>involved and no obvious reason why it couldn't be done=2E  The major prob=
lem
>here has always been the indefinite amount of code implicated by calling
>datatype input functions, and we have now created a plausible answer to
>that problem=2E

I'm not even sure it makes sense to avoid that kind of error=2E And invali=
d column count or such is something quite different than failing some data =
type input routine, or falling a constraint=2E=20


--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E