On Fri, Oct 28, 2022 at 7:53 PM Andrey Lepikhov
wrote:
> On 28/10/2022 16:12, Etsuro Fujita wrote:
> > I think there is another patch that improves performance of COPY FROM
> > for foreign tables using COPY FROM STDIN, but if Andrey (or anyone
> > else) want to work on it again, I think it would b
On 28/10/2022 16:12, Etsuro Fujita wrote:
On Thu, Oct 13, 2022 at 6:58 PM Etsuro Fujita wrote:
I have committed the patch after tweaking comments a little bit further.
I think there is another patch that improves performance of COPY FROM
for foreign tables using COPY FROM STDIN, but if Andrey
On Thu, Oct 13, 2022 at 6:58 PM Etsuro Fujita wrote:
> I have committed the patch after tweaking comments a little bit further.
I think there is another patch that improves performance of COPY FROM
for foreign tables using COPY FROM STDIN, but if Andrey (or anyone
else) want to work on it again,
On Thu, Oct 13, 2022 at 1:38 PM Andrey Lepikhov
wrote:
> On 10/12/22 07:56, Etsuro Fujita wrote:
> > On Tue, Oct 11, 2022 at 3:06 PM Andrey Lepikhov
> > wrote:
> >> I reviewed the patch one more time. Only one question: bistate and
> >> ri_FdwRoutine are strongly bounded. Maybe to add some assert
On 10/12/22 07:56, Etsuro Fujita wrote:
On Tue, Oct 11, 2022 at 3:06 PM Andrey Lepikhov
wrote:
I reviewed the patch one more time. Only one question: bistate and
ri_FdwRoutine are strongly bounded. Maybe to add some assertion on
(ri_FdwRoutine XOR bistate) ? Just to prevent possible errors in f
On Tue, Oct 11, 2022 at 3:06 PM Andrey Lepikhov
wrote:
> I reviewed the patch one more time. Only one question: bistate and
> ri_FdwRoutine are strongly bounded. Maybe to add some assertion on
> (ri_FdwRoutine XOR bistate) ? Just to prevent possible errors in future.
You mean the bistate member o
On 10/7/22 11:18, Etsuro Fujita wrote:
On Tue, Sep 27, 2022 at 6:03 PM Etsuro Fujita wrote:
I will review the patch a bit more, but I feel that it is
in good shape.
One thing I noticed is this bit added to CopyMultiInsertBufferFlush()
to run triggers on the foreign table.
+ /* Run
On Tue, Sep 27, 2022 at 6:03 PM Etsuro Fujita wrote:
> I will review the patch a bit more, but I feel that it is
> in good shape.
One thing I noticed is this bit added to CopyMultiInsertBufferFlush()
to run triggers on the foreign table.
+ /* Run AFTER ROW INSERT triggers */
+
On Wed, Aug 10, 2022 at 5:30 PM Etsuro Fujita wrote:
> On Wed, Aug 10, 2022 at 1:06 AM Zhihong Yu wrote:
> > + /* If any rows were inserted, run AFTER ROW INSERT triggers. */
> > ...
> > + for (i = 0; i < inserted; i++)
> > + {
> > + TupleTa
On Tue, Aug 23, 2022 at 2:58 PM Andrey Lepikhov
wrote:
> 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
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,
On Mon, Aug 15, 2022 at 2:29 PM Andrey Lepikhov
wrote:
> On 8/9/22 16:44, Etsuro Fujita wrote:
> >>> -1 foo
> >>> 1 bar
> >>> \.
> > ERROR: new row for relation "t1" violates check constraint "t1_f1positive"
> > DETAIL: Failing row contains (-1, foo).
> > CONTEXT: remote SQL command: INSERT INT
On 8/9/22 16:44, Etsuro Fujita wrote:
-1 foo
1 bar
\.
ERROR: new row for relation "t1" violates check constraint "t1_f1positive"
DETAIL: Failing row contains (-1, foo).
CONTEXT: remote SQL command: INSERT INTO public.t1(f1, f2) VALUES
($1, $2), ($3, $4)
COPY ft1, line 3
In single-insert mode
Hi,
On Wed, Aug 10, 2022 at 1:06 AM Zhihong Yu wrote:
> On Tue, Aug 9, 2022 at 4:45 AM Etsuro Fujita wrote:
>> * When running AFTER ROW triggers in CopyMultiInsertBufferFlush(), the
>> patch uses the slots passed to ExecForeignBatchInsert(), not the ones
>> returned by the callback function, but
On Tue, Aug 9, 2022 at 4:45 AM Etsuro Fujita
wrote:
> On Tue, Jul 26, 2022 at 7:19 PM Etsuro Fujita
> wrote:
> > Yeah, I think the patch is getting better, but I noticed some issues,
> > so I'm working on them. I think I can post a new version in the next
> > few days.
>
> * When running AFTER
On Tue, Jul 26, 2022 at 7:19 PM Etsuro Fujita wrote:
> Yeah, I think the patch is getting better, but I noticed some issues,
> so I'm working on them. I think I can post a new version in the next
> few days.
* When running AFTER ROW triggers in CopyMultiInsertBufferFlush(), the
patch uses the sl
On Wed, Jul 27, 2022 at 2:42 PM Andrey Lepikhov
wrote:
> On 7/22/22 13:14, Etsuro Fujita wrote:
> > On Fri, Jul 22, 2022 at 3:39 PM Andrey Lepikhov
> > wrote:
> >> Analyzing multi-level heterogeneous partitioned configurations I
> >> realized, that single write into a partition with a trigger wil
On 7/22/22 13:14, Etsuro Fujita wrote:
On Fri, Jul 22, 2022 at 3:39 PM Andrey Lepikhov
wrote:
Analyzing multi-level heterogeneous partitioned configurations I
realized, that single write into a partition with a trigger will flush
buffers for all other partitions of the parent table even if the
On Fri, Jul 22, 2022 at 5:42 PM Andrey Lepikhov
wrote:
> So, maybe switch
> status of this patch to 'Ready for committer'?
Yeah, I think the patch is getting better, but I noticed some issues,
so I'm working on them. I think I can post a new version in the next
few days.
Best regards,
Etsuro Fu
On 7/22/22 13:14, Etsuro Fujita wrote:
On Fri, Jul 22, 2022 at 3:39 PM Andrey Lepikhov
Why such cascade flush is really necessary, especially for BEFORE and
INSTEAD OF triggers?
BEFORE triggers on the chosen partition might query the parent table,
not just the partition, so I think we need to
On Fri, Jul 22, 2022 at 3:39 PM Andrey Lepikhov
wrote:
> Analyzing multi-level heterogeneous partitioned configurations I
> realized, that single write into a partition with a trigger will flush
> buffers for all other partitions of the parent table even if the parent
> haven't any triggers.
> It
On 7/20/22 13:10, Etsuro Fujita wrote:
On Tue, Jul 19, 2022 at 6:35 PM Andrey Lepikhov
wrote:
On 18/7/2022 13:22, Etsuro Fujita wrote:
I rewrote the decision logic to something much simpler and much less
invasive, which reduces the patch size significantly. Attached is an
updated patch. What
On Tue, Jul 19, 2022 at 6:35 PM Andrey Lepikhov
wrote:
> On 18/7/2022 13:22, Etsuro Fujita wrote:
> > I rewrote the decision logic to something much simpler and much less
> > invasive, which reduces the patch size significantly. Attached is an
> > updated patch. What do you think about that?
>
On 18/7/2022 13:22, Etsuro Fujita wrote:
On Thu, Mar 24, 2022 at 3:43 PM Andrey V. Lepikhov
wrote:
On 3/22/22 06:54, Etsuro Fujita wrote:
* To allow foreign multi insert, the patch made an invasive change to
the existing logic to determine whether to use multi insert for the
target relation, a
On Thu, Mar 24, 2022 at 3:43 PM Andrey V. Lepikhov
wrote:
> On 3/22/22 06:54, Etsuro Fujita wrote:
> > * To allow foreign multi insert, the patch made an invasive change to
> > the existing logic to determine whether to use multi insert for the
> > target relation, adding a new member ri_usesMulti
On 11/7/2022 04:12, Ian Barwick wrote:
On 09/07/2022 00:09, Andrey Lepikhov wrote:
On 8/7/2022 05:12, Ian Barwick wrote:
ERROR: bind message supplies 0 parameters, but prepared
statement "pgsql_fdw_prep_178" requires 6
CONTEXT: remote SQL command: INSERT INTO public.foo_part_1(t,
v
On 09/07/2022 00:09, Andrey Lepikhov wrote:
On 8/7/2022 05:12, Ian Barwick wrote:
ERROR: bind message supplies 0 parameters, but prepared statement
"pgsql_fdw_prep_178" requires 6
CONTEXT: remote SQL command: INSERT INTO public.foo_part_1(t, v1, v2, v3,
v4, v5) VALUES ($1, $2, $3,
On 8/7/2022 05:12, Ian Barwick wrote:
ERROR: bind message supplies 0 parameters, but prepared statement
"pgsql_fdw_prep_178" requires 6
CONTEXT: remote SQL command: INSERT INTO public.foo_part_1(t, v1,
v2, v3, v4, v5) VALUES ($1, $2, $3, $4, $5, $6)
COPY foo, line 88160
Thanks,
On 07/07/2022 22:51, Andrey Lepikhov wrote:
> On 7/7/2022 06:14, Ian Barwick wrote:
>> 2022年3月24日(木) 15:44 Andrey V. Lepikhov :
>> >
>> > On 3/22/22 06:54, Etsuro Fujita wrote:
>> > > On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov
>> > > wrote:
>> > >> We still have slow 'COPY FROM' operatio
On 7/7/2022 06:14, Ian Barwick wrote:
2022年3月24日(木) 15:44 Andrey V. Lepikhov :
>
> On 3/22/22 06:54, Etsuro Fujita wrote:
> > On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov
> > wrote:
> >> We still have slow 'COPY FROM' operation for foreign tables in
current
> >> master.
> >> Now we ha
2022年3月24日(木) 15:44 Andrey V. Lepikhov :
>
> On 3/22/22 06:54, Etsuro Fujita wrote:
> > On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov
> > wrote:
> >> We still have slow 'COPY FROM' operation for foreign tables in current
> >> master.
> >> Now we have a foreign batch insert operation And I tried
On 3/22/22 06:54, Etsuro Fujita wrote:
On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov
wrote:
We still have slow 'COPY FROM' operation for foreign tables in current
master.
Now we have a foreign batch insert operation And I tried to rewrite the
patch [1] with this machinery.
The patch has been
On Tue, Mar 22, 2022 at 8:58 AM Andres Freund wrote:
>
> On 2021-06-07 16:16:58 +0500, Andrey Lepikhov wrote:
> > Second version of the patch fixes problems detected by the FDW regression
> > tests and shows differences of error reports in tuple-by-tuple and batched
> > COPY approaches.
>
> Patch
On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov
wrote:
> We still have slow 'COPY FROM' operation for foreign tables in current
> master.
> Now we have a foreign batch insert operation And I tried to rewrite the
> patch [1] with this machinery.
I’d been reviewing the previous version of the patch
On 2021-06-07 16:16:58 +0500, Andrey Lepikhov wrote:
> Second version of the patch fixes problems detected by the FDW regression
> tests and shows differences of error reports in tuple-by-tuple and batched
> COPY approaches.
Patch doesn't apply and likely hasn't for a while...
Second version of the patch fixes problems detected by the FDW
regression tests and shows differences of error reports in
tuple-by-tuple and batched COPY approaches.
--
regards,
Andrey Lepikhov
Postgres Professional
From 68ad02038d7477e005b65bf5aeeac4efbb41073e Mon Sep 17 00:00:00 2001
From: "A
On 4/6/21 13:45, tsunakawa.ta...@fujitsu.com wrote:
From: Andrey Lepikhov
We still have slow 'COPY FROM' operation for foreign tables in current master.
Now we have a foreign batch insert operation And I tried to rewrite the patch
[1]
with this machinery.
I haven't looked at the patch, but n
From: Andrey Lepikhov
> We still have slow 'COPY FROM' operation for foreign tables in current master.
> Now we have a foreign batch insert operation And I tried to rewrite the patch
> [1]
> with this machinery.
I haven't looked at the patch, but nice performance.
However, I see the following p
Hi,
We still have slow 'COPY FROM' operation for foreign tables in current
master.
Now we have a foreign batch insert operation And I tried to rewrite the
patch [1] with this machinery.
The patch (see in attachment) smaller than [1] and no changes required
in FDW API.
Benchmarking
=
39 matches
Mail list logo
