Subject: Re: Is there any limit on the number of rows to import using copy command

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Jul 2025 12:18:52 +0000 (UTC)

Thanks Merlin, adrain, Laurenz
As a testcase, I split the trigger function into three, one each for insert, update, delete, each called from a separate trigger.  
IT WORKS!.
Shouldn't we have one trigger function for all the three trigger events?  Is it prohibited for bulk insert like this?
I tried this in PGAdmin only, will complete the testing from the program which we are developing, after my return from holiday.
Happiness Always
BKR Sivaprakash
    On Wednesday 23 July, 2025 at 11:20:03 pm IST, Merlin Moncure <[email-masked]> wrote:  
 
 On Wed, Jul 23, 2025 at 2:51 AM [email-masked]
<[email-masked]> wrote:
>
> Tried in PostgreSQL 11.11 , PostgreSQL 15.2 in Windows 10
>
> Here we try to transfer data from one database to another (remote) database.
>
> Tables do have records ranging from 85000 to 3600000 along with smaller sized tables.
> No issues while transferring smaller 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 triggers, one to arrive a closing value and other to delete, if the closing value is zero.
>
> 1.  Transfer the data from source database to a csv file.  85000 records transferred. No issues.
> 2.  Transfer the file to the remote location.  No issues.
> 3.  Transfer the contents of the file to the table using Copy From command. - Fails when try to transfer all the 85000 records at once.
>
> Copy from command is
>
> Copy public.table1 From 'E:\temp\file1.csv' (FORMAT CSV, DELIMITER ',', HEADER TRUE)
>
> The above command succeeds, when
> 1.  The trigger 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 Trigger and other constraints in table1 enabled.  We waited for 1.5 hrs first time and 2.5 hrs second time before cancelling the operation.
>
> I read in the documentation that the fastest way to transfer data is to use 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.

Most likely, you are getting yourself into trouble with the trigger
dependencies.  Triggers are powerful, but also can be dangerous, and
this could be 'wrong tool for the job' situation.

 Here are some general tips:

* pg_trigger_depth(): can tell you if trigger A calls trigger B and
back to trigger A, etc.  you can use it with raise notify, and also
use it to guard execution on CREATE TRIGGER

* reconfiguring your logic to statement level triggers can be a good
idea. this can take some thinking, but can be much more efficient when
bulk processing since trigger execution can be deferred until the load
completes. (one trick is to use now() to check for records inserted
since it is stable though the transaction)

* reconfiguring your logic to a procedure can be a better idea; COPY
your data into some staging tables (perhaps temp, and indexed), then
write to various tables with joins, upserts, etc.

merlin

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 24 Jul 2025 07:48:04 -0700

On 7/24/25 05:18, [email-masked] wrote:
> As a testcase, I split the trigger function into three, one each for 
> insert, update, delete, each called from a separate trigger.
> 
> IT WORKS!.

It worked before, it just slowed down as your cases got bigger. You need 
to provide more information on what test case you used and how you 
define worked.

> 
> Shouldn't we have one trigger function for all the three trigger 
> events?  Is it prohibited for bulk insert like this?

No. Triggers are overhead and they add to the processing that need to be 
done for moving the data into the table. Whether that is an issue is a 
case by case determination.

> 
> I tried this in PGAdmin only, will complete the testing from the program 
> which we are developing, after my return from holiday.

 From Merlin Moncure's post:

"* reconfiguring your logic to a procedure can be a better idea; COPY
your data into some staging tables (perhaps temp, and indexed), then
write to various tables with joins, upserts, etc."

I would suggest looking into implementing the above.

-- 
Adrian Klaver
[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Jul 2025 23:59:33 +0000 (UTC)

1.  Testcase.  Created a new database, modified the triggers (split into three), populated required master data, lookup tables.  Then transferred 86420 records. Checked whether all the 86420 records inserted in table1 and also whether the trigger created the required records in table2.   Yes, it created.
2.  In the test case above, the total time taken to insert 86420 records is 1.15 min only.   Earlier (before splitting the triggers) we waited for more than 1.5 hrs first time and 2.5 hrs second time with no records inserted.
3.  Regarding moving the logic to procedure.  Won't the trigger work?  Will it be a burden for 86420 records?  It's working, if we insert few thousand records.  After split of trigger function, it's working for 86420 records.  Are triggers overhead for handling even 100000 records?  In production system, the same (single) trigger is working with 3 millions of records.  There might be better alternatives to triggers, but triggers should also work.  IMHO.
4.  Staging tables.  Yes, I have done that in another case, where there was a need to add data / transform for few more columns.  It worked like a charm.  In this case, since there was no need for any other calculations (transformation), and with just column to column matching, I thought copy command will do.
Before splitting the trigger into three, we tried1.  Transferring data using DataWindow / PowerBuilder (that's the tool we use to develop our front end).  With the same single trigger, it took few hours (more than 4 hours, exact time not noted down) to transfer the same 86420 records.  (Datawindow fires insert statements for every row).  Works, but the time taken is not acceptable.
2.  Next, we split the larger csv file into 8, with each file containing 10,000 records and the last one with 16420 records.  Copy command worked.  Works, but the time taken to split the file not acceptable.  We wrote a batch file to split the larger csv file.  We felt batch file is easier to automate the whole process using PowerBuilder.
3.  What we observed here, is insert statement succeeds and copy command fails, if the records exceed a certain no.  Haven't arrived the exact number of rows when the copy command fails.
Will do further works after my return from a holiday.
Happiness Always
BKR Sivaprakash

    On Thursday 24 July, 2025 at 08:18:07 pm IST, Adrian Klaver <[email-masked]> wrote:

---

From: Ron Johnson <[email-masked]>
Date: Thu, 24 Jul 2025 20:41:34 -0400

On Thu, Jul 24, 2025 at 8:00 PM [email-masked] <
[email-masked]> wrote:
[snip]

> 3.  Regarding moving the logic to procedure.  Won't the trigger work?
> Will it be a burden for 86420 records?  It's working, if we insert few
> thousand records.  After split of trigger function, it's working for 86420
> records.  Are triggers overhead for handling even 100000 records?
>

What causes the overhead when a trigger fires is all the work that it has
to do.

Thus, if the SELECT or UPDATE statements in the triggers do not have good
index support, then _that_ is what will slow down the trigger as the number
of records gets bigger.   Of course, the triggers are not slow, it's the
statements in the trigger that are slow.

Likewise, if there are many many indices on the tables, that will slow
things down too: more indices means more work!
Thus, drop as many indices as possible before loading data.

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: Adrian Klaver <[email-masked]>
Date: Thu, 24 Jul 2025 17:48:53 -0700

On 7/24/25 16:59, [email-masked] wrote:
> 1.  Testcase.  Created a new database, modified the triggers (split into 
> three), populated required master data, lookup tables.  Then transferred 
> 86420 records. Checked whether all the 86420 records inserted in table1 
> and also whether the trigger created the required records in table2.  
>   Yes, it created.
> 
> 2.  In the test case above, the total time taken to insert 86420 records 
> is 1.15 min only.   Earlier (before splitting the triggers) we waited 
> for more than 1.5 hrs first time and 2.5 hrs second time with no records 
> inserted.
> 
> thousand records.  After split of trigger function, it's working for 
> 86420 records.  Are triggers overhead for handling even 100000 records?  
> In production system, the same (single) trigger is working with 3 
> millions of records.  There might be better alternatives to triggers, 
> but triggers should also work.  IMHO.

Reread this post, in the thread, from Laurenz Albe:

https://www.postgresql.org/message-id/de08fd016dd9c630f65c52b80292550e0bcdea4c.camel%40cybertec.at

> 
> 4.  Staging tables.  Yes, I have done that in another case, where there 
> was a need to add data / transform for few more columns.  It worked like 
> a charm.  In this case, since there was no need for any other 
> calculations (transformation), and with just column to column matching, 
> I thought copy command will do.

There is a transformation, you are moving data to another table. That is 
overhead, especially if the triggers are not optimized.

> 
> Before splitting the trigger into three, we tried
> 1.  Transferring data using DataWindow / PowerBuilder (that's the tool 
> we use to develop our front end).  With the same single trigger, it took 
> few hours (more than 4 hours, exact time not noted down) to transfer the 
> same 86420 records.  (Datawindow fires insert statements for every 
> row).  Works, but the time taken is not acceptable.

INSERTs by row is going to be slow, especially if the tool is doing a 
commit for each which I suspect it is. Check the Postgres logs.

> 
> 2.  Next, we split the larger csv file into 8, with each file containing 
> 10,000 records and the last one with 16420 records.  Copy command 
> worked.  Works, but the time taken to split the file not acceptable.  We 
> wrote a batch file to split the larger csv file.  We felt batch file is 
> easier to automate the whole process using PowerBuilder.

I find most GUI tools create extra steps and overhead. My preference are 
simpler tools e.g. using Python csv module to batch/stream rows that the 
Python psycopg2 Postgres driver can insert or copy into the database.
See:

https://www.psycopg.org/psycopg3/docs/basic/copy.html

> 
> 3.  What we observed here, is insert statement succeeds and copy command 
> fails, if the records exceed a certain no.  Haven't arrived the exact 
> number of rows when the copy command fails.
> 
> On 7/24/25 05:18, [email-masked] <mailto:[email-masked]> 
> wrote:
> [email-masked] <mailto:[email-masked]>
>