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 1ueY4Z-00B96Q-Cf for pgsql-general@arkaria.postgresql.org; Wed, 23 Jul 2025 11:55:48 +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 1ueY4Y-002431-ID for pgsql-general@arkaria.postgresql.org; Wed, 23 Jul 2025 11:55:46 +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 1ueY4X-00242t-LI for pgsql-general@lists.postgresql.org; Wed, 23 Jul 2025 11:55:46 +0000 Received: from sonic301-20.consmr.mail.sg3.yahoo.com ([106.10.242.83]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ueY4V-000NfG-1v for pgsql-general@postgresql.org; Wed, 23 Jul 2025 11:55:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1753271739; bh=f/L4AdpS9xC7mv6gs7/YTkD655tZCSmdeMZ3anq7Ung=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=sd019KA5Hf6FbDVJGgls9LaYGIhh5s+rUJCOirRhRN0K/T2X9mRy2rd5rG9BugBxMJ4mFpRmBfQDz8cXJNOz+uESJL+dfZqsvdeFC7SGOfrwKhNrPc5acv14M0DdZyl0oaxU4EAM6pxtz4jzyZCKnu08TNzv8/kdGLd+4tHLbaA0gZdI9xj2V68HP32TCcZej9cKiPVOuOSAWd4fZRnEXPd1wf0e8XRd3Kf6SX5mBwXrMy8yp7N/iJwMtt+Ave7JbJAMzMB0vj9PpdLmduT87fFCWm7CH64DwR0aB/PPVZCrp/E88MKddrRm1ZeDVqI/uYk1Pj9Q4NtKd1uTzPPz1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1753271739; bh=pFdjXCuezN59o0HBN3Uqm9LcfCU7rtdgNJOjA0AzB3U=; h=X-Sonic-MF:X-Sonic-MF:Date:From:To:Subject:From:Subject; b=hXUydLLUIgaSbFPjj4SYmevaB3uysZiSjAXBpCceTR3XxHu4S4JSS5XsMjPzFPA/buNIKxKi0bbz2AneYUYvwT+zSAhzU+U0OxQM8sZdshLUIskdDww72ep4J5hb+sWZBhrHhE5n0WuBO1lcjj7KNg3OKRgvqvo8eSkcL11n69UlLJvjrSYL7oNAYHuEsDOmPwPfIyR0vioU/xgdHq5VFDZRSoAu/TtAthIEgp1OojTbcq52RVrCJa48rQwZaB2WClZrWijGAUUyT+r4vxceBzQz4P0Wd+SE3V5lUK1pxK04n9nNOvR1aQ7YWfI+FPq3jYIlcdx1dJH+sH7i1rpMOw== X-YMail-OSG: iJ9Qql0VM1kGMFq.q5CDPZ29vc61KPrEhnUz1Kh6B_DA2YB9KbEjBJwAtH7Y25g Gl4hNmQnG8Y_L1lyYKnizbRdMIqBDJyNUVxoQBhybA8cIKIlWdVgEQLuFFhWH1PDojMsMlxVSy.a WHB65CrJ20CK3IiMrGEazMEMIcerUKWwko18retQCX_71vUHEIGT6TYe2Xfjakqo_FWgKtxKHCfs RJAObLff6yuHEKniXf6Ds.ILGY2aKf.H9dMWLkvSmFrKF_PjNV9zzWhezLGnB4rFZHWjHF0W2zU0 ktXp3cSXBswFFCSUIP4aedj2qV4DpUVJTGqzqkjOMW7Y5oALnd1yGrEXodAhDFAChU3.eQdBr3lr gyI2ljFvT1SAMlvRs9HlEg5xOcP.dcUM.gItvbWHQXlSK7JJaTL6pleweEZnHmgHEBsjwxFhYliN J8udtEFXYQaobzOmQS1CKeave1.h7JwD0x56eb32w8lIJt6b9izNdE5nK9Vt7ZPxqx7aE20LLvD6 z7Rb4qzeWplE0GdOCX3OHMMsBaogf8yhpE7vbomjaa7UOpRi18syA7AzP5VAX8X7KYMZfkZM6QG7 e2NUrRQAogbw1A4lN_caXJ6Zp6utuBz8alVp34W2VCFA7dsRaraoaKyeYAhDjdeGW4jnbUC0OS9S X2Cpg2G_l6yr2rwWECa0jwwQ4hw0NXdR2MvhOTavaYFeGBQrSyeLwFHcrMUdt0zioexXm1BTC5XV mS7CpudY7oTuklWYsYKphULg0kAaWOPkIRZ9pW94HFGFw7pcMTpqe9cb3nypmfdMpiGcTKQWi6GF VLurAPvFmnokfgyKqjTS.1LBn_fckNG8CH.JjtXEG3KOGk5lDxZpw8VRtz013srVGqDWlhLZU.Ol VVNvJjpg5BtWC.r5NyEIsBr6tUx6CGHEH6PRes3Ljqb_9JfrUezCEeGEDjrzux2bH.vXt4Fs.kkY uIaUniuYoVOLQ7Y8hGfdOL274GWculgyGWhqux3a7tmiZRhN8B6SSFC8mPoR6J_hhIjdYGq9PG9G CLp0an.bh6RNk7BXLPaXyOTW.t12CF4SrEVMBAOSIJuFDalvqyt47JOOQxxF8MpSADHdu25PImOe 9__.TVt75yg.PlKPUlIBLfRXpLm6GNeSqao.xdfJqIN8_dVCqa96idd_aF.vui6N31jWs3iJAFvN 9_gBVWeIK_KdYXqCBpSZcAqRWLQ7JMB6pA8G5nwtZ1p9R2PdI6HcpNeNAmTPgbQJ8TtHpKZCB_Wh E.dwxZW8Y0QN2nyClAvAzsm68NvKx0q2jNWKL.ZN3w4amSKa.oWBCxBwlT3nsuvneYefjohxEmA3 PRRsYKxrPu4xIWuq38VCXz6bSIhrDR9RV3V84gxXBMw9tn8SVzq9c.NYZy6bQFeGSKQGhy7TmcDr R66B8HjtWVrpqAL39WUi0nlS3R4WIksCF9h0x416fLhHvTtGm7OLt_F75uwLTewLLwvYrHp8UM.S 3CZeb668oXx3avRqEKlRcLzGtwmi5Ew52eW3oGKWABHUq64tu4A16hvv8_yHKhipF1kgjO_OIfMU Q.Az6yjC.oi64nnRekhOfSqDdkbkTLMczQeoobWmntpzqMwHo9rtUU.n_ETn4Q4sJ7y5d6yIEurJ eR.hw.zMUdLSSe0aC4YCNxOsx80UlZGoLgkS1tplwhdONOWKLFFRER2WU6PbfRtlq3omP9xKd8NQ 6WfDdsW4653fpYsOoN6HSd8gGvXLNvCISsQW_vIenBzUQianyC3Qrk70RC4MT2ub2MCN5APnaXxr 2VtyVNkyqARbQxXCgNzDtUaIR.ZUXdHKJaYYIUyC5F9vl6C2pQn26YCuu9h3zUdXR4PdGvoompmr ESEY0_vQMYOaBzlKA18cDez.VtyXRkmiy9HNmsexLzJO_hiI2Lf5XkB6PVpDvZLZ07T6kblCDIr8 2TUgLXh2Kme.DiNcSykmbpN0blBKch1jTSq6B6jGJuxgHLsOvGzm8yCTYb42Us2Cbq4WgCMt0JJa Pi7jCjVqPYzWHz1doHNXKWqLWLwL8Ad7FKGLNn6bEvhnYtYy1tN584cVd.T_1qKcY_RKuTDDZm51 THXwrzdGf8Hd47fnZXrEHaLoXNp0tNKKKwr9kCQ64tYS2ccwcmuDcj9t2cyzEsmJoTqT.zdAtJP3 N04X07krtE6ZxpT5YgldwMoMZHAqjxm76dKuseefXbd4NuT_kiIb6H7TMFe8e7DHgNBEYLRf.Vp4 rRc.dZLTR329SsVy9nmUnjBMfVgHNK2q9Ii08uUvrDho_cIhq1hzgFCzw87NvrJUZPWwksDNQtur S.4FYReDhyaj_ECXX9B.42w-- X-Sonic-MF: X-Sonic-ID: 1f91703d-8420-4731-b9f9-6f4a2c3d060a Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.sg3.yahoo.com with HTTP; Wed, 23 Jul 2025 11:55:39 +0000 Received: by hermes--production-gq1-74d64bb7d7-dp9cd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c7ef4583c0402789d0c50ab8c84ee70e; Wed, 23 Jul 2025 11:55:35 +0000 (UTC) X-YMail-OSG: oOYbDgcVM1mxjOHcWWa_xCm3cC3x4Hfmh.yCWHolkd3tBTEzZvD9clCvtAjHplj Y4BN0l.Zo.mNiz0fWzB3q7bsYVlnRQdCV9xG_YtMUdxpXCMXvJKrKY5m23yfbhq8XRk6LEhSUSGa r0Sulw2fiDm7JcyxodZlHhj4vhurZe8hb7ytgpS9fBGotPJYQQ.HNe2n.HqhzSNZqVMQ1OcBOGec osJFPnHhKLeCOVeXnI4k3m2pS5IaY5Y_UtUMIDqbqoM.rFbPfe.Fs15IznB7JUfOxmXXLt0Qo7vL cnOfkRYK6RC3hFhVRVh0lFVKfE_wt4n7xjNrld3vBe7ERse4Cjfor4HoxXGqKvFw2uilxRVPFL3n AsU.nygFO0J0jZYw4YQff0hhxQ4o4Q.7zy5_BNxoJ6jDduvqFvsb1kuhUnLMYIJPZpu23GjyrtT. Eb4K1qh6h00zQqURejEue.ImRcZ3rRkPIPXD1Av3qSZPzzyrnhic14dDNRMTzQHBi1pQ5FPQJX70 DW56xYb.jwhCApBMNG5weJnBvTPRR9YxxWTA87FuiLNR5tuK09tEei8GBBjrdOYuAOQQ6APdwbr5 oiEkNsE6Z0oCNtlx6QGcAPuf_f4Zt28rpD3xFIT45Pg62PvwN14vbTLAf34JGL59XX6pn80mMjn8 oCl9bfg_bM0UwW5hXsM88.vP61ydgp8YIathev0XCgrSN_Thng3vI2OtOCD.aIftHhchnADsyqdV 521uKioFd.g1.CxJIqvxE0pMvnIdggtaULfJDipKbDazL3QFhQz3_1xz4bXTSI5omKk5SgCVgiyw STl6qeb4e9YfvwJexJXLhpemlBqMljjO7Lt0miIXm8qMaWsuYK5XlX6OLhjp5sjiN_90.NWupbn8 5nwxOgRJkqisRJ69rODKCKIxoAx3e1TUc.TLZx1CT0z2NaNhYh74sxMXOhEZjwBd7QKjMfgvPU7_ CZRFaOnDBZmWCFp1o1cseFgQi2lq.VZ92TlaW3ibopnZhGp3sEAlAXaK4q39_OyCBhtxxGq4kcJo dnBtTcJ5nW3VAsDfJSXq0n8N3zk04b5OWIY.AzYwEOD3wjdIxRt3a2FgwNNuPErrFVbUuYXJ490w MCDbdwGDnmmndIbEWdW74svUV0pGREeJmEAyw_k3Vmw8I_dsul4xlCJjfhvKE6oPlRbcytcoQAo8 fowOOWgIqPZQjTvUetPrYoxcS5xVdqI6.eh.Irdi74oIIlmS.p1SzzpzKMeQ3JXt_5VN0aNaO7da HIpfSA2zv6hZ8sgj54YIMimdUy5RKXs2emGWOeozge6DjPMmu7bOn_9JB9b3qqmBqYMvFPTK4Cqr 3ySY5SPPo347ixuJhlnNAI_GNh1MxcBtjpc24Xdvc2Ir4IuMEir2mFRYqCBVhe5zjU6iqvMoZd8T ikkysuS4SZXgUn5nS.HMqUwujLIJZ11N9qS99d_RBoBK_p9qIpgqmrx5VK6yuIFcJEX56PQMsGq4 pIutEarr7CicUQnzXrgG.uitH11732_aUvwY6ELUhrQwr3zFPPuCsjX7QwUQKDiSqZPLXBb1TCwi lDQ9XxaBk_WBMJOmM370ElqpJFrfzccNbiTf9CUPuE5qDdgA6vhB67WwSioEIMqXBiYDEArs3uY1 _uO85n4d4DSvLyzbOW6GtxnX3KVXQOXDvge1Oji1X5CclxLV2ZGeITShV6wd3go6yhAOVbmyw43c JvCAaFpXnLem1KkJXAHza19ze0x3YQwxAuqLcxIPWCPCKxlpp4gYFsyHuZg2GHdJ3TGLXRZ7b6mG KaBMNti1MaIq5iaX8JzVAt0uLxhneUIndpCCdQ.9xtBEiAU5vYWyCPYA53T8YDEzeUDVIpA8PNg4 nUMAL0YmKN.af8xFYd9c466xkc5KUWTkyiH39UfkomuJg8hakOhZzns0kcCrZfJMfvFKsPYEkfiT EQGzI53gR2Rqo0LY_1UpO4_jqGZZn4KKrsr4vYbLz5VUHz9UThANh8RWneAxHvMUw4FZPRt9aHxe 9q4mTlvNBXqyRP7.swtH1qLKar1rLNRZD5fEfH6Wnke8H6OlJoS.gyLEWVGVabJOOgazcTn2upUs Ul9FoQRxoCuORosFp9jvMeKHMPj0w9sp6RI1EG_khixyoUk1ZrAvjpe_eAQEHgB4LSb7rLbq9Xhr 5jdSrgVl.1RmBMA5U3hW5cs5fxJi9QzhO6Yv8zVf2.fFI4ER2ExBvAvUs_cCp4DGb_fzA_RO6Ll1 ukVHv53Y7CQ8Umq0QTpZpO1iPKkvrz6QHQ.EjVmO0gUirJrHCCgqzwqpbXPce4i2ggqjrlQEFsuC 2.tiMwqhhhSSHEKKqxY4WgPoy2VI1Sf7vqpo1gODmK4J9g4lswRiOetQG3GvoW77Ior9UMPLUuCS C X-Sonic-MF: X-Sonic-ID: bccd911c-7b0b-4a8d-be53-a09587a281c8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Jul 2025 11:55:34 +0000 Date: Wed, 23 Jul 2025 11:55:29 +0000 (UTC) From: "sivapostgres@yahoo.com" Reply-To: "sivapostgres@yahoo.com" To: Pgsql-general , Laurenz Albe Message-ID: <959901171.1916220.1753271729336@mail.yahoo.com> In-Reply-To: References: <1453510076.1900935.1753260637232.ref@mail.yahoo.com> <1453510076.1900935.1753260637232@mail.yahoo.com> Subject: Re: Is there any limit on the number of rows to import using copy command MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1916219_1260611076.1753271729334" X-Mailer: WebService/1.1.24187 YMailNorrin Content-Length: 12651 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_1916219_1260611076.1753271729334 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Laurenz Albe, 1.=C2=A0 I tried running Copy From command from PGAdmin.=C2=A0=C2=A02.=C2= =A0 I ran pg_stat_activity also in another tab [ PGAdmin ]. What I observed,1.=C2=A0 In about 2 min, in the Dashboard of PGAdmin, the c= olour changed to Orange for that particular pid.2.=C2=A0 After few seconds,= the colour again changed to Red.=C2=A0 =C2=A03.=C2=A0 The stat column in b= oth Dashboard and pg_stat_activity.state shows 'active'.4.=C2=A0 No message= s relevant to this pid in postgres' log files5.=C2=A0 CPU usage is normal, = hovering around 36% overall, 15-18% for postgresql server, from the beginni= ng and even after 3 min.6.=C2=A0 We didn't run any other application in tha= t machine.=C2=A0=C2=A07.=C2=A0 Unique Index is there in table2 which will r= eturn only one row for that Select Count(*) query.8.=C2=A0 No record is the= re in the target table when transfer started.=C2=A0 This transfer is the fi= rst batch for that particular table.9.=C2=A0 Once color turned into Red, I = could cancel the query execuion in PGAdmin, which immediately stops the exe= cution.10. I could not see any locks or blocking pids. Happiness Always BKR Sivaprakash On Wednesday 23 July, 2025 at 03:46:40 pm IST, Laurenz Albe wrote: =20 =20 On Wed, 2025-07-23 at 08:50 +0000, sivapostgres@yahoo.com wrote: > Tried in PostgreSQL 11.11 , PostgreSQL 15.2 in Windows 10 Both of these choices are unsavory.=C2=A0 Don't use the unsupported v11, and use 15.13 with v15. > Here we try to transfer data from one database to another (remote) databa= se.=C2=A0 >=20 > Tables do have records ranging from 85000 to 3600000 along with smaller s= ized tables. > No issues while transferring smaller sized tables. >=20 > I here take one particular table [table1] which has 85000 records. > The table got Primary Key, Foreign Key(s), Triggers.=C2=A0 Trigger update= s another table [table2] > Table2 have 2 triggers, one to arrive a closing value and other to delete= , if the closing value is zero. >=20 > 1.=C2=A0 Transfer the data from source database to a csv file.=C2=A0 8500= 0 records transferred. No issues. > 2.=C2=A0 Transfer the file to the remote location.=C2=A0 No issues. > 3.=C2=A0 Transfer the contents of the file to the table using Copy From c= ommand. - Fails when try to transfer all the 85000 records at once.=C2=A0= =C2=A0 >=20 > Copy from command is >=20 > Copy public.table1 From 'E:\temp\file1.csv' (FORMAT CSV, DELIMITER ',', H= EADER TRUE) >=20 > The above command succeeds, when > 1.=C2=A0 The trigger in Table1 is disabled with all other constraints on. > 2.=C2=A0 The no. of rows is within 16000 or less, with Trigger enabled.= =C2=A0 We haven't tried with higher no of rows. >=20 > The above command goes on infinite loop, when > 1.=C2=A0 We try to transfer all 85000 rows at once, with Trigger and othe= r constraints in table1 enabled. >=C2=A0 =C2=A0 =C2=A0 We waited for 1.5 hrs first time and 2.5 hrs second t= ime before cancelling the operation. >=20 > I read in the documentation that the fastest way to transfer data is to u= se Copy command. > And I couldn't find any limit in transferring data using that command. > One could easily transfer millions of rows using this command. There is no limit for the number of rows that get created by a single COPY. You should research why processing fails for higher row counts: - Are there any messages on the client or the server side? - Is the backend process on the server busy (consuming CPU) when processing= hangs? - Do you see locks or other wait events in "pg_stat_activity"? > Here are the triggers. >=20 > Trigger function, which is called from Table1 on After Insert, Update, De= lete One thing you could try is a BEFORE trigger.=C2=A0 That should work the sam= e, unless there are foreign key constraints.=C2=A0 Do you see high memory usage or pa= ging for the backend process when the COPY hangs? > [...] > If (Select Count(*) > =C2=A0From=C2=A0 =C2=A0table2 > =C2=A0WHERE=C2=A0 companycode =3D company_code > =C2=A0AND=C2=A0 =C2=A0 branchcode=C2=A0 =3D branch_code > =C2=A0AND=C2=A0 =C2=A0 locationfk=C2=A0 =3D location_fk > =C2=A0AND=C2=A0 =C2=A0 barcode=C2=A0 =C2=A0 =C2=A0=3D variety_code ) > 0 = Then > [...] That may well be slow, particularly without a matching index. A better way to write that would be =C2=A0 IF EXISTS (SELECT 1 FROM table2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WHERE ...) because that can stop processing after the first match. It still needs an index for fast processing. Yours, Laurenz Albe =20 ------=_Part_1916219_1260611076.1753271729334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Laurenz Albe,

1.  I tried running Copy From command from PGAdmin. &n= bsp;
2.  I ran pg_stat_act= ivity also in another tab [ PGAdmin ].

What I observed,
1.  In about 2 min, in the = Dashboard of PGAdmin, the colour changed to Orange for that particular pid.=
2.  After few seconds, th= e colour again changed to Red.   
3.  The stat column in both Dashboard and pg_stat_activit= y.state shows 'active'.
4. = ; No messages relevant to this pid in postgres' log files
5.  CPU usage is normal, hovering around 36= % overall, 15-18% for postgresql server, from the beginning and even after = 3 min.
6.  We didn't run a= ny other application in that machine.  
7.  Unique Index is there in table2 which will retu= rn only one row for that Select Count(*) query.
8.  No record is there in the target table when trans= fer started.  This transfer is the first batch for that particular tab= le.
9.  Once color turned = into Red, I could cancel the query execuion in PGAdmin, which immediately s= tops the execution.
10. I could= not see any locks or blocking pids.

Happiness Always
= BKR Sivaprakash

=20
=20
On Wednesday 23 July, 2025 at 03:46:40 pm IST, Laur= enz Albe <laurenz.albe@cybertec.at> wrote:


=20 =20
On Wed, 2025-07-23 at 08:50 +0000, sivapostgres@yahoo.com wrote:
&= gt; Tried in PostgreSQL 11.11 , PostgreSQL 15.2 in Windows 10

Both of these choices are unsavory.  Don't use= the unsupported v11,
and use 15.13 with v15.

> Here we try to transfer data from one databa= se to another (remote) database. 
>
> Tables do have records ranging from 85000 to 3600000 along with = smaller sized tables.
> No issues while transferring s= maller sized tables.
>
> I here = take one particular table [table1] which has 85000 records.
> The table got Primary Key, Foreign Key(s), Triggers.  Trigger = updates another table [table2]
> Table2 have 2 trigger= s, one to arrive a closing value and other to delete, if the closing value = is zero.
>
> 1.  Transfer t= he data from source database to a csv file.  85000 records transferred= . No issues.
> 2.  Transfer the file to the remot= e location.  No issues.
> 3.  Transfer the c= ontents of the file to the table using Copy From command. - Fails when try = to transfer all the 85000 records at once.  
&g= t;
> Copy from command is
>
> Copy public.table1 From 'E:\temp\file1.csv' (FORMAT CSV= , DELIMITER ',', HEADER TRUE)
>
>= ; The above command succeeds, when
> 1.  The trig= ger in Table1 is disabled with all other constraints on.
= > 2.  The no. of rows is within 16000 or less, with Trigger enabled= .  We haven't tried with higher no of rows.
> > The above command goes on infinite loop, when
> 1.  We try to transfer all 85000 rows at once, with Tri= gger and other constraints in table1 enabled.
>  =     We waited for 1.5 hrs first time and 2.5 hrs second time befo= re cancelling the operation.
>
>= I read in the documentation that the fastest way to transfer data is to us= e Copy command.
> And I couldn't find any limit in tra= nsferring data using that command.
> One could easily = transfer millions of rows using this command.

There is no limit for the number of rows that get created by a si= ngle COPY.

You should research why pro= cessing fails for higher row counts:
- Are there any mess= ages on the client or the server side?
- Is the backend p= rocess on the server busy (consuming CPU) when processing hangs?
- Do you see locks or other wait events in "pg_stat_activity"?
> Here are the triggers.
>
> Trigger function, which is called from T= able1 on After Insert, Update, Delete

= One thing you could try is a BEFORE trigger.  That should work the sam= e, unless
there are foreign key constraints.  Do you= see high memory usage or paging for
the backend process = when the COPY hangs?

> [...]
> If (Select Count(*)
>  From = ;  table2
>  WHERE  companycode =3D com= pany_code
>  AND    branchcode  = =3D branch_code
>  AND    locationfk&nb= sp; =3D location_fk
>  AND    barcode&n= bsp;    =3D variety_code ) > 0 Then
> [..= .]

That may well be slow, particularly= without a matching index.
A better way to write that wou= ld be

  IF EXISTS (SELECT 1 FROM = table2

&nb= sp;           WHERE ...)

=
because that can stop processing after the first match.<= br clear=3D"none">It still needs an index for fast processing.

Yours,
Laurenz Albe

------=_Part_1916219_1260611076.1753271729334--