From: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, tanghy(dot)fnst(at)fujitsu(dot)com, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, houzj(dot)fnst(at)fujitsu(dot)com |
Subject: | Re: Fast COPY FROM based on batch insert |
Date: | 2022-08-23 05:58:22 |
Message-ID: | 30b35bf3-6bfc-c52c-cccf-aec3d5f6e76d@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22/8/2022 11:44, Etsuro Fujita wrote:
> I think the latter is more consistent with the existing error context
> information when in CopyMultiInsertBufferFlush(). Actually, I thought
> this too, and I think this would be useful when the COPY FROM command
> is executed on a foreign table. My concern, however, is the case when
> the command is executed on a partitioned table containing foreign
> partitions; in that case the input data would not always be sorted in
> the partition order, so the range for an error-occurring foreign
> partition might contain many lines with rows from other partitions,
> which I think makes the range information less useful. Maybe I'm too
> worried about that, though.
I got your point. Indeed, perharps such info doesn't really needed to be
included into the core, at least for now.
--
regards,
Andrey Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2022-08-23 06:03:03 | Re: [PATCH] Optimize json_lex_string by batching character copying |
Previous Message | Julien Rouhaud | 2022-08-23 05:56:11 | Re: Schema variables - new implementation for Postgres 15 |