Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rIVh2-0094jE-Kn for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Dec 2023 15:19:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rIVg2-006lZc-Iw for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Dec 2023 15:18:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rIVg2-006lZU-9L for pgsql-hackers@lists.postgresql.org; Wed, 27 Dec 2023 15:18:34 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rIVfv-00CSUK-KE for pgsql-hackers@postgresql.org; Wed, 27 Dec 2023 15:18:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3BRFILWm2495252; Wed, 27 Dec 2023 10:18:21 -0500 From: Tom Lane To: Robins Tharakan cc: "Kumar, Sachin" , Nathan Bossart , Jan Wieck , Bruce Momjian , Zhihong Yu , Andrew Dunstan , Magnus Hagander , Peter Eisentraut , "pgsql-hackers@postgresql.org" Subject: Re: pg_upgrade failing for 200+ million Large Objects In-reply-to: References: <986904.1616525964@sss.pgh.pa.us> <6cccaa33-c263-b8a2-b064-985605d33d25@wi3ck.info> <988415.1616528159@sss.pgh.pa.us> <872315a8-99fc-da4e-463d-784cfb5a025d@wi3ck.info> <1010642.1616532950@sss.pgh.pa.us> <802b96e9-f5e1-015c-dfb9-8756974b11fc@wi3ck.info> <0263bf35-05d6-02a1-519b-b7895a918314@wi3ck.info> <20220825003227.GA1456581@nathanxps13> <663393ca-b2ff-26f0-2e2d-adc942aff4fd@timescale.com> <20220908231807.GA2242918@nathanxps13> <0643CC11-223A-4039-AC34-94E127462796@amazon.com> <1152134.1699555261@sss.pgh.pa.us> <83D44BE5-0088-4D41-8AE6-20A05D026F46@amazon.com> <81D13E16-BA04-43CF-9B89-B8924300B211@amazon.com> <240D05EC-8B28-4112-BEAB-85ECBAF3F871@amazon.com> <2055911.1702258962@sss.pgh.pa.us> <534746.1703116064@sss.pgh.pa.us> Comments: In-reply-to Robins Tharakan message dated "Wed, 27 Dec 2023 23:58:01 +1030" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2495250.1703690301.1@sss.pgh.pa.us> Date: Wed, 27 Dec 2023 10:18:21 -0500 Message-ID: <2495251.1703690301@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robins Tharakan writes: > Applying all 4 patches, I also see good performance improvement. > With more Large Objects, although pg_dump improved significantly, > pg_restore is now comfortably an order of magnitude faster. Yeah. The key thing here is that pg_dump can only parallelize the data transfer, while (with 0004) pg_restore can parallelize large object creation and owner-setting as well as data transfer. I don't see any simple way to improve that on the dump side, but I'm not sure we need to. Zillions of empty objects is not really the use case to worry about. I suspect that a more realistic case with moderate amounts of data in the blobs would make pg_dump look better. regards, tom lane