Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQCt3-0002mc-L2 for pgsql-performance@arkaria.postgresql.org; Fri, 04 Mar 2022 18:42:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nQCt2-0000Yw-Ea for pgsql-performance@arkaria.postgresql.org; Fri, 04 Mar 2022 18:42:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQCt2-0000YP-4u for pgsql-performance@lists.postgresql.org; Fri, 04 Mar 2022 18:42:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQCsz-0000Zm-Ok for pgsql-performance@lists.postgresql.org; Fri, 04 Mar 2022 18:42:43 +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 224IgdY33967141; Fri, 4 Mar 2022 13:42:39 -0500 From: Tom Lane To: aditya desai cc: Pgsql Performance Subject: Re: Any way to speed up INSERT INTO In-reply-to: References: Comments: In-reply-to aditya desai message dated "Sat, 05 Mar 2022 00:01:52 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3967139.1646419359.1@sss.pgh.pa.us> Date: Fri, 04 Mar 2022 13:42:39 -0500 Message-ID: <3967140.1646419359@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk aditya desai writes: > One of the service layer app is inserting Millions of records in a table > but one row at a time. Although COPY is the fastest way to import a file in > a table. Application has a requirement of processing a row and inserting it > into a table. Is there any way this INSERT can be tuned by increasing > parameters? It is taking almost 10 hours for just 2.2 million rows in a > table. Table does not have any indexes or triggers. Using a prepared statement for the INSERT would help a little bit. What would help more, if you don't expect any insertion failures, is to group multiple inserts per transaction (ie put BEGIN ... COMMIT around each batch of 100 or 1000 or so insertions). There's not going to be any magic bullet that lets you get away without changing the app, though. It's quite possible that network round trip costs are a big chunk of your problem, in which case physically grouping multiple rows into each INSERT command (... or COPY ...) is the only way to fix it. But I'd start with trying to reduce the transaction commit overhead. regards, tom lane