Re: row filtering for logical replication
От | Euler Taveira |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | c3eb4ba6-0da5-4f4d-88f8-b42894f2e6d4@www.fastmail.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: row filtering for logical replication
|
Список | pgsql-hackers |
On Mon, Dec 6, 2021, at 3:35 AM, Dilip Kumar wrote:
On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira <euler@eulerto.com> wrote:>> On Fri, Dec 3, 2021, at 8:12 PM, Euler Taveira wrote:>> PS> I will update the commit message in the next version. I barely changed the> documentation to reflect the current behavior. I probably missed some changes> but I will fix in the next version.>> I realized that I forgot to mention a few things about the UPDATE behavior.> Regardless of 0003, we need to define which tuple will be used to evaluate the> row filter for UPDATEs. We already discussed it circa [1]. This current version> chooses *new* tuple. Is it the best choice?But with 0003, we are using both the tuple for evaluating the rowfilter, so instead of fixing 0001, why we don't just merge 0003 with0001? I mean eventually, 0003 is doing what is the agreed behavior,i.e. if just OLD is matching the filter then convert the UPDATE toDELETE OTOH if only new is matching the filter then convert the UPDATEto INSERT. Do you think that even we merge 0001 and 0003 then alsothere is an open issue regarding which row to select for the filter?
Maybe I was not clear. IIUC we are still discussing 0003 and I would like to
propose a different default based on the conclusion I came up. If we merged
0003, that's fine; this change will be useless. If we don't or it is optional,
it still has its merit.
Do we want to pay the overhead to evaluating both tuple for UPDATEs? I'm still
processing if it is worth it. If you think that in general the row filter
contains the primary key and it is rare to change it, it will waste cycles
evaluating the same expression twice. It seems this behavior could be
controlled by a parameter.
В списке pgsql-hackers по дате отправления: