Re: Time delayed LR (WAS Re: logical replication restrictions)
От | Amit Kapila |
---|---|
Тема | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Дата | |
Msg-id | CAA4eK1+yT-V0M3fiC-h-R=Jfwoy6K3AGceGqLh8af8Uyqwc_xw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Time delayed LR (WAS Re: logical replication restrictions) ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: Time delayed LR (WAS Re: logical replication restrictions)
RE: Time delayed LR (WAS Re: logical replication restrictions) |
Список | pgsql-hackers |
On Fri, Apr 28, 2023 at 2:35 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear hackers, > > I rebased and refined my PoC. Followings are the changes: > 1. Is my understanding correct that this patch creates the delay files for each transaction? If so, did you consider other approaches such as using one file to avoid creating many files? 2. For streaming transactions, first the changes are written in the temp file and then moved to the delay file. It seems like there is a double work. Is it possible to unify it such that when min_apply_delay is specified, we just use the delay file without sacrificing the advantages like stream sub-abort can truncate the changes? 3. Ideally, there shouldn't be a performance impact of this feature on regular transactions because the delay file is created only when min_apply_delay is active but better to do some testing of the same. Overall, I think such an approach can address comments by Sawada-San [1] but not sure if Sawada-San or others have any better ideas to achieve this feature. It would be good to see what others think of this approach. [1] - https://www.postgresql.org/message-id/CAD21AoAeG2%2BRsUYD9%2BmEwr8-rrt8R1bqpe56T2D%3DeuO-Qs-GAg%40mail.gmail.com -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: