Re: Logical Replication WIP

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, Steve Singer <steve(at)ssinger(dot)info>
Subject: Re: Logical Replication WIP
Date: 2016-09-14 19:19:42
Message-ID: d5fc3a57-9c86-4905-c60b-7e920f08ad5c@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14/09/16 20:50, Andres Freund wrote:
> On 2016-09-14 13:20:02 -0500, Peter Eisentraut wrote:
>> On 9/14/16 11:21 AM, Andres Freund wrote:
>>>> + ExecInsert(NULL, /* mtstate is only used for onconflict handling which we don't support atm */
>>>>> + remoteslot,
>>>>> + remoteslot,
>>>>> + NIL,
>>>>> + ONCONFLICT_NONE,
>>>>> + estate,
>>>>> + false);
>>> I have *severe* doubts about just using the (newly) exposed functions
>>> 1:1 here.
>>
>> It is a valid concern, but what is the alternative? ExecInsert() and
>> the others appear to do exactly the right things that are required.
>
> They're actually a lot more heavyweight than what's required. If you
> e.g. do a large COPY on the source side, we create a single executor
> state (if at all), and then insert the rows using lower level
> routines. And that's *vastly* faster, than going through all the setup
> costs here for each row.
>
>
>> Are your concerns mainly philosophical about calling into internal
>> executor code, or do you have technical concerns that this will not do
>> the right thing in some cases?
>
> Well, not about it being wrong in the sene of returning wrong results,
> but wrong in the sense of not even remotely being able to keep up in
> common cases.
>

I'd say in common case they will. I don't plan to use these forever btw,
but it's simplest to just use them in v1 IMHO instead of trying to
reinvent new versions of these that perform better but also behave
correctly (in terms of triggers and stuff for example).

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-09-14 19:44:13 Re: Comment on GatherPath.single_copy
Previous Message Petr Jelinek 2016-09-14 19:17:42 Re: Logical Replication WIP