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-vGSkaOYDgyeKk_0YWHeSaoOi+Xg2V44A1pmSuiMd7Pqw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Thu, Oct 1, 2020 at 9:19 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Oct 1, 2020 at 8:22 AM Keisuke Kuroda > <keisuke.kuroda.3862@gmail.com> wrote: > > > > Hi Dilip, Amit, > > > > Thank you for the patch! > > > > I test the patch on the master HEAD(9796f455) and it works fine. > > * make installcheck-world: passed > > * walsender process continues to use 100% of the CPU 1core when > > TRUNCATE 1000 partition: 1s or less > > ** before patch : 230s > > > > Does this result indicate that it is still CPU bound but it does the > actual decoding and completes in 1s instead of spending 230s mainly to > execute unnecessary invalidations? > > > There is "ReorderBufferAddInvalidation" in reorderbuffer.h, but I > > don't think it's needed. > > > > src/include/replication/reorderbuffer.h > > +void ReorderBufferAddInvalidation(ReorderBuffer *, TransactionId, > > XLogRecPtr lsn, > > + int nmsgs, SharedInvalidationMessage *msgs); > > > > From the patch perspective, I think it is better if we can add one > test case as well where we process some invalidations and then the > rollback happens and we need to process all the invalidations > together. Basically, this is to cover the new code, if such a test > already exists then it is fine. I think we already have such a test case. 019_stream_subxact_ddl_abort.pl is covering this scenario. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: