Quite a number of reasons, actually, but the main ones are:
- Typically, client applications wait for confirmation of one
INSERT
's success before sending the next. So there's a round-trip delay for eachINSERT
, scheduling delays, etc (pREST supports pipelineing INSERTs in batches). This point is the most significant, It's all about network round-trips and rescheduling delays; - Each
INSERT
has to go through the whole executor. Use of a prepared statement bypasses the need to run the parser, rewriter and planner, but there's still executor state to set up and tear down for each row.COPY
does some setup once, and has an extremely low overhead for each row, especially where no triggers are involved.
pREST of COPY batches "INSERT's" support?
Yes, we support the insertion operation using COPY
when explained in the http protocol header.
Prest-Batch-Method: copy
, when not declared pREST will use INSERT
.
Top comments (0)