Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

On Fri, Oct 2, 2020 at 12:26 PM Keisuke Kuroda
<keisuke(dot)kuroda(dot)3862(at)gmail(dot)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.
>
> Also, the argument of palloc was still MemoryContextAlloc,
> which prevented me from applying the patch, so I've only fixed that part.
>
> # test script
>
> Please set PGHOME and CLUSTER_PUB before run.
>
> sh test_pg_recvlogical.sh
>
> # perf command
>
> perf record --call-graph dwarf -p [walsender pid]
> perf report -i perf.data --no-children
>
> # before patch
>
> decode + invalidation = 222s
>
> 2020-10-02 14:55:50 BEGIN 509
> 2020-10-02 14:59:42 table nsp_001.tbl_001, nsp_001.part_0001 ...
> nsp_001.part_0999, nsp_001.part_1000: TRUNCATE: (no-flags)
> 2020-10-02 14:59:42 COMMIT 509 (at 2020-10-02 14:55:50.349219+09)

I could not see this issue even without the patch, it is taking less
than 1s even without the patch. See below results

2020-10-08 13:00:49 BEGIN 509
2020-10-08 13:00:49 table nsp_001.part_0001: INSERT:...
2020-10-08 13:00:49 COMMIT 509 (at 2020-10-08 13:00:48.741986+05:30)

Am I missing something?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com