Re: MERGE ... WHEN NOT MATCHED BY SOURCE

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: MERGE ... WHEN NOT MATCHED BY SOURCE
Дата
Msg-id CAEZATCWdnEjzKAb7JB4Af5_wgitEiT2hCpMeCMPBPjm4QA1npg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MERGE ... WHEN NOT MATCHED BY SOURCE  (Ted Yu <yuzhihong@gmail.com>)
Список pgsql-hackers
On Sat, 21 Jan 2023 at 14:18, Ted Yu <yuzhihong@gmail.com> wrote:
>
> On Sat, Jan 21, 2023 at 3:05 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>>
>> Rebased version, following 8eba3e3f02 and 5d29d525ff.
>>

Another rebased version attached.

> In transform_MERGE_to_join :
>
> +                       if (action->matchKind == MERGE_WHEN_NOT_MATCHED_BY_SOURCE)
> +                               tgt_only_tuples = true;
> +                       if (action->matchKind == MERGE_WHEN_NOT_MATCHED_BY_TARGET)
>
> There should be an `else` in front of the second `if`.
> When tgt_only_tuples and src_only_tuples are both true, we can come out of the loop.
>

I decided not to do that. Adding an "else" doesn't change the code
that the compiler generates, and IMO it's slightly more readable
without it, since it keeps the line length shorter, and the test
conditions aligned, but that's a matter of opinion / personal
preference.

I think adding extra logic to exit the loop early if both
tgt_only_tuples and src_only_tuples are true would be a premature
optimisation, increasing the code size for no real benefit. In
practice, there are unlikely to be more than a few merge actions in
the list.

Regards,
Dean

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rinat Shigapov
Дата:
Сообщение: Too coarse predicate locks granularity for B+ tree indexes
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Minimal logical decoding on standbys