On Tue, Jun 9, 2020 at 3:39 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Jun 4, 2020 at 5:06 PM Mahendra Singh Thalor <mahi6...@gmail.com> > wrote: >> >> On Fri, 29 May 2020 at 15:52, Amit Kapila <amit.kapil...@gmail.com> wrote: >> > >> >> >> To see all the operations(DDL's and DML's), please see test_results >> >> Testing summary: >> Basically, we are writing per command invalidation message and for testing >> that I have tested with different combinations of the DDL and DML operation. >> I have not observed any performance degradation with the patch. For "create >> index" DDL's, %change in wal is 1-7% for 1-15 DDL's. For "add col int/date" >> DDL's, it is 11-17% for 1-15 DDL's and for "add col text" DDL's, it is 2-6% >> for 1-15 DDL's. For mix (DDL & DML), it is 2-10%. >> >> why are we seeing 11-13 % of the extra wall, basically, the amount of extra >> WAL is not very high but the amount of WAL generated with add column >> int/date is just ~1000 bytes so additional 100 bytes will be around 10% and >> for add column text it is ~35000 bytes so % is less. For text, these ~35000 >> bytes are due to toast >> There is no change in wal size for DML operations. For savepoints, we are >> getting max 8 bytes per savepoint wal increment (basically for >> Sub-transaction, we are adding 5 bytes to store xid but due to padding, it >> is 8 bytes and some times if wal is already aligned, then we are getting 0 >> bytes increment) > > > So, if I read it correctly, there is no performance penalty with either of > the patches but there is some additional WAL which in most cases is 2-5% but > in worst cases and some specific DDL's it is upto 15%. I think as this WAL > overhead is when wal_level is logical, we might have to live with it as the > other alternative is to blew up all caches on any DDL in WALSenders and that > will have bot CPU and Network overhead as expalined previously [1]. I feel > if the WAL overhead pinches any workload, we might want to do it under some > new guc (which will disable streaming of transactions) but I don't think we > need to go there. > > What do you think?
Even I feel so because the WAL overhead is only with wal_level=logical and especially with DDL and ideally, there should not be a large amount of DDL in the system compared to other operations. So I think we can live with the current approach. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
