pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Zhihong Yu <zyu@yugabyte.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: tanghy.fnst@fujitsu.com, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: houzj.fnst@fujitsu.com
Subject: Re: Fast COPY FROM based on batch insert
Date: Tue, 23 Aug 2022 08:58:22 +0300
Message-ID: <30b35bf3-6bfc-c52c-cccf-aec3d5f6e76d@postgrespro.ru> (raw)
In-Reply-To: <CAPmGK15r9RjMUnpavRUh7jXag9S+MEvNSSkevnPj+y3QxTzWpQ@mail.gmail.com>
References: <TYAPR01MB2990B8451B4C725242E270F7FE979@TYAPR01MB2990.jpnprd01.prod.outlook.com>
	<CAPmGK15rVM+61WHZ3xS3zS6mq7293zCexVMYV4p3xoyTYo8FLg@mail.gmail.com>
	<bc489202-9855-7550-d64c-ad2d83c24867@postgrespro.ru>
	<CAPmGK15Z1kvZE0oULa+JD_CKzc4NwWEZYAfJ26VkoVYg1md63g@mail.gmail.com>
	<45ad1b94-339b-a841-8885-67ebe6fc5bc1@postgrespro.ru>
	<CAPmGK14ov-MbQtwHuSK5ESUeL1csgCVC1MAAwZxgV=NWsBE2ZQ@mail.gmail.com>
	<57733596-5fd6-07ec-d65c-67411411f10e@postgrespro.ru>
	<CAPmGK145252jR4fygMTtJcUA4fCoKPkbykir9p9XupT6N903fQ@mail.gmail.com>
	<05bc8819-3e53-d884-a0d0-a17ffa5febef@postgrespro.ru>
	<CAPmGK15jd6gEt_XyswQ4uEG6XVdz9DNC5uqW1KK=1A_ehLTEYw@mail.gmail.com>
	<09ff35ff-291f-d9e9-a0ed-55e6bb9732fc@postgrespro.ru>
	<CAPmGK15WWjXsyBE05vDjvi37012WTiW-j=-Y8Uo=VqPRpsbOgg@mail.gmail.com>
	<CAPmGK15ZqOfE4N0PknZMzW96DRdZOA8ih_7591JMqAZu-Nhiiw@mail.gmail.com>
	<9b293a07-c822-a326-6ff2-4a9e0e9e5549@postgrespro.ru>
	<CAPmGK15r9RjMUnpavRUh7jXag9S+MEvNSSkevnPj+y3QxTzWpQ@mail.gmail.com>

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





view thread (39+ messages)  latest in thread

Message-ID: <30b35bf3-6bfc-c52c-cccf-aec3d5f6e76d@postgrespro.ru>
Permalink:  ../30b35bf3-6bfc-c52c-cccf-aec3d5f6e76d@postgrespro.ru/
Also on:    postgresql.org/message-id/30b35bf3-6bfc-c52c-cccf-aec3d5f6e76d@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: a.lepikhov@postgrespro.ru, etsuro.fujita@gmail.com, pryzby@telsasoft.com, zyu@yugabyte.com, amitlangote09@gmail.com, ashutosh.bapat.oss@gmail.com, tomas.vondra@enterprisedb.com, houzj.fnst@fujitsu.com
  Subject: Re: Fast COPY FROM based on batch insert
  In-Reply-To: <30b35bf3-6bfc-c52c-cccf-aec3d5f6e76d@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox