Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d9HF2-0000ZC-D6 for pgsql-general@arkaria.postgresql.org; Fri, 12 May 2017 20:32:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d9HF1-0001xe-Qr for pgsql-general@arkaria.postgresql.org; Fri, 12 May 2017 20:32:47 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d9HF0-0001vs-6c for pgsql-general@postgresql.org; Fri, 12 May 2017 20:32:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d9HEx-0003gf-Jl for pgsql-general@postgresql.org; Fri, 12 May 2017 20:32:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v4CKWfvH028462; Fri, 12 May 2017 16:32:41 -0400 From: Tom Lane To: Mathieu Fenniak cc: Andres Freund , pgsql-general@postgresql.org Subject: Re: Logical decoding CPU-bound w/ large number of tables In-reply-to: References: <20170506012055.hhmx5hirj2yk7d3g@alap3.anarazel.de> <19256.1494034347@sss.pgh.pa.us> <20170506013810.2og6vax6a2u3rhjc@alap3.anarazel.de> <12184.1494450131@sss.pgh.pa.us> <20170510211025.scae63m476ftv7i3@alap3.anarazel.de> Comments: In-reply-to Mathieu Fenniak message dated "Fri, 12 May 2017 14:19:10 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28460.1494621161.1@sss.pgh.pa.us> Date: Fri, 12 May 2017 16:32:41 -0400 Message-ID: <28461.1494621161@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org Mathieu Fenniak writes: > I've taken your patches, Tom, and applied them to a test deployment of my > actual application. > The most accessible way I have to reproduce this issue is to run a > maintenance task that we typically run during a software deployment, which > will remove some tenant schemas from our database system. I ran that task > with and without the patches, and monitored how long logical replication > stalled. This test was on a database with 22 schemas containing 400 tables > each (~8800 tables). > As a baseline, PostgreSQL 9.5.6 stalled completely for 21m 13s > PostgreSQL 9.5.6 + all three patches stalled completely for 4m 11s. > Definitely a fantastic improvement. :-) Thanks for confirming that these patches help in a real-world scenario. Obviously there's still room for improvement, but I think it's worth pushing what I've done, so I'll go do that. I hope Andres will follow up with trying to improve matters from the other angle. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general