Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
От | Dilip Kumar |
---|---|
Тема | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |
Дата | |
Msg-id | CAFiTN-vhH=JWZQeBdo+7D5wdezVJUK_driscPyP5D2f-Ma8vZw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables (Keisuke Kuroda <keisuke.kuroda.3862@gmail.com>) |
Список | pgsql-hackers |
On Fri, Oct 2, 2020 at 12:26 PM Keisuke Kuroda <keisuke.kuroda.3862@gmail.com> wrote: > > Hi Dilip, Amit, > > > > 5. Can you please once repeat the performance test done by Keisuke-San > > > to see if you have similar observations? Additionally, see if you are > > > also seeing the inconsistency related to the Truncate message reported > > > by him and if so why? > > > > > > > Okay, I will set up and do this test early next week. Keisuke-San, > > can you send me your complete test script? > > Yes, I've attached a test script(test_pg_recvlogical.sh) > > Sorry, the issue with TRUNCATE not outputting was due to a build miss > on my part. > Even before the patch, TRUNCATE decodes and outputting correctly. > So, please check the performance only. > > I have tested it again and will share the results with you. Okay, thanks for confirming I will test. > Also, the argument of palloc was still MemoryContextAlloc, > which prevented me from applying the patch, so I've only fixed that part. Oh my bad, I think I forgot to amend that part in the patch after compiling. Thanks for fixing this. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: