Thread: Difference between Bulk Load (Multiple inserts or single inserts) and COPY

Difference between Bulk Load (Multiple inserts or single inserts) and COPY

From
PG Doc comments form
Date:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/10/sql-copy.html
Description:

Hello, 

Myself Mayank. I am a Ph.D. student.

I experimented with Bulk load and COPY.
Loading in COPY was very fast. 
However, after COPYing data from a CSV file to PostgreSQL Table. The query
execution took lot of time for 1 of the first 4 queries.
Only this slow query was taking so much time, that even if I had used normal
bulk load, it would have been faster in total.
Then all other Query executions took equal time as it took while querying a
table after the Bulk data load method.

So, I want to know the exact reason what's the issue with COPY.
How exactly they differ? The only thing from the document I could identify
was row security.
But it did not mention anything about indexing. Like, in Bulk load, do
indices(or constraint checks) are created with data loading?
& in COPY it's done after? so when indices are being created that query
slows down??

Please reply soon with more details or send a link where I can read it in
depth.
Thanks.
Mayank.
mayank.l.patel90@gmail.com

Re: Difference between Bulk Load (Multiple inserts or singleinserts) and COPY

From
Laurenz Albe
Date:
On Tue, 2019-11-19 at 18:55 +0000, PG Doc comments form wrote:
> I experimented with Bulk load and COPY.
> Loading in COPY was very fast. 
> However, after COPYing data from a CSV file to PostgreSQL Table. The query
> execution took lot of time for 1 of the first 4 queries.
> Only this slow query was taking so much time, that even if I had used normal
> bulk load, it would have been faster in total.
> Then all other Query executions took equal time as it took while querying a
> table after the Bulk data load method.
> 
> So, I want to know the exact reason what's the issue with COPY.
> How exactly they differ? The only thing from the document I could identify
> was row security.
> But it did not mention anything about indexing. Like, in Bulk load, do
> indices(or constraint checks) are created with data loading?
> & in COPY it's done after? so when indices are being created that query
> slows down??
> 
> Please reply soon with more details or send a link where I can read it in
> depth.

That cannot be answered without knowing the exact statements and the
table definitions.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com




Re: Difference between Bulk Load (Multiple inserts or singleinserts) and COPY

From
Bruce Momjian
Date:
On Tue, Nov 19, 2019 at 11:55:44PM +0100, Laurenz Albe wrote:
> On Tue, 2019-11-19 at 18:55 +0000, PG Doc comments form wrote:
> > I experimented with Bulk load and COPY.
> > Loading in COPY was very fast. 
> > However, after COPYing data from a CSV file to PostgreSQL Table. The query
> > execution took lot of time for 1 of the first 4 queries.
> > Only this slow query was taking so much time, that even if I had used normal
> > bulk load, it would have been faster in total.
> > Then all other Query executions took equal time as it took while querying a
> > table after the Bulk data load method.
> > 
> > So, I want to know the exact reason what's the issue with COPY.
> > How exactly they differ? The only thing from the document I could identify
> > was row security.
> > But it did not mention anything about indexing. Like, in Bulk load, do
> > indices(or constraint checks) are created with data loading?
> > & in COPY it's done after? so when indices are being created that query
> > slows down??
> > 
> > Please reply soon with more details or send a link where I can read it in
> > depth.
> 
> That cannot be answered without knowing the exact statements and the
> table definitions.

I wonder if it is the overhead of rewriting all the rows to set the
per-row HEAP_XMIN_COMMITTED bit.  Unfortunately, I don't know a way to
test this hypothesis.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +