Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
| От | Fujii Masao |
|---|---|
| Тема | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Дата | |
| Msg-id | CAHGQGwEeJ6ijS=d5byU0Pq1J9YYGw+X=fyomd_d71sx5NOHdsA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect (Chao Li <li.evan.chao@gmail.com>) |
| Ответы |
Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Список | pgsql-hackers |
On Sat, Nov 22, 2025 at 10:31 AM Chao Li <li.evan.chao@gmail.com> wrote: > > > > > On Nov 22, 2025, at 00:14, Fujii Masao <masao.fujii@gmail.com> wrote: > > > > On Fri, Nov 21, 2025 at 6:24 PM Chao Li <li.evan.chao@gmail.com> wrote: > >> No, what I was thinking is that, we could combine the three set statement into one, like: > >> > >> ``` > >> Set a = 1; set b = 2; set c = 3; > >> ``` > >> So that sends a single statement to publisher server, that reduces round-trip from 3 times to one time. > > > > I see the point about combining the three SET commands to reduce round trips, > > but I think the current approach in the patch (i.e., issuing a separate > > SET command for each parameter) is sufficient. I still don't think > > the additional round trip during replication connection startup is > > a real concern. This approach is also consistent with what postgres_fdw > > and pg_dump already do. > > > > No problem. I don’t have a strong option here. I just saw you mentioned overhead of round trip and thought to improve.But I agree that overhead is tiny, not a real concern. Okay, thanks! I've updated the patch to use lengthof() as you suggested. The revised version is attached. Regards, -- Fujii Masao
Вложения
В списке pgsql-hackers по дате отправления: